On Wed, Mar 9, 2011 at 1:53 PM, Tim Niemueller tim@niemueller.de wrote:
On 09.03.2011 19:33, Martin Langhoff wrote:
On Wed, Mar 9, 2011 at 1:19 PM, Tim Niemueller tim@niemueller.de wrote:
That still is way to vague. I suggest creating a package per robot/board/platform/sensor/actuator. If there is a canonical software
We are talking about 1 package for a 1-line file. That's very OCD :-)
One single package simplifies maintenance for this maintainer, reduces metadata load on fedora infra, cuts your "yum downloading metadata" times.
I know, but one catch-all package is just not the proper way.
Well that's just an unfounded statement.
I have an NXT, a GoGo board, a Pico/Scratch board all on my desk right now. I'll get my hands on a wedo and arduino kit soon.
They are _extremely_ similar, they are actually are all variations on a theme; just like printers are. All have 3 to 5 inputs (usually read as an unsigned int) and 3 to 5 "controller" ports. Some have a cpu you get to program, plus a tiny bit of RAM. They all cost < USD 100 (or around $250 in a kit with sensors and motors).
If the API (and CPU/RAM) allows, you can copy some bytecode files to the device and execute them independently. Otherwise you read the inputs and write commands to the controller ports.
They are _so_ similar, that we control them all from TurtleArt, or from Scratch. Their sensors are mostly the same across different boards.
Is there any problem if we end up with a package with udev rules for 50 similar-ish robots that can be controlled by more than one library? Why are the bluetooth and printer rpm maintainers not hitting that problem? File a bug against their packages too ;-)
m