|
Hi, Tim Niemueller <tim@xxxxxxxxxxxxx> wrote on 02/03/2011 2:32:43 AM +0350: I also agree with Tim. If there are any kind of drivers or libraries which is used for accessing a specific hardware, corresponding udev rules can be packaged with that driver of library.On 02.02.2011 23:29, Martin Langhoff wrote:thoughts?I think udev rules should be in the package driving the hardware, not somewhere else in a robot-control package. For example, openni-primesense (in review) carries such a file for the PrimeSense and Kinect, and I don't see that this should belong anywhere else. I don't like that centralization. However, it seems that lego NXT robot's device doesn't have any special accessing libraries, and packages like nbc and nxt_python access the device file directly. Anyway, many hardware parts of robots do have such drivers, and that's the better place to put udev rules (and probably policykit rules?!). If the policykit rule is common for all robot devices (e.g. devices under a specific group like "robot-control" group), it can be packaged in a single package which robotic device packages depend on. Or, as Tim proposed below be integrated in udev and/or PolicyKit packages themselves. Now, if lego NXT doesn't have any drivers (isn't there any common code in both nbc and nxt_python which can be extracted as a separate package?); then I think using a package just for udev (& PK) rules is fine. Small packages is not anything new (e.g. Fonts SIG has some rules for font packaging which can result in many small packages). In fact, with appropriate package provides, we can also automate the process of installing required packages for a specific hardware (like what is now done for printer drivers and fonts). For example, you'll plug a lego nxt robot for the first time, and PackageKit automatically prompts you for installing appropriate driver/udev/PK rules package. I'm not saying that we should go for it, but it can be done! Good luck, Hedayat I'd think different if I'm just misunderstanding your proposal and you are in fact proposing some kind of framework. So your package would setup a group to which robot devices can be assigned, which are then magically accessible by the console user, and for which hardware packages only contain udev rules of the form "device identifier -> assign to robot group". But then, why not add this framework to the udev package in the first place? Tim |
_______________________________________________ robotics mailing list robotics@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/robotics
