> > I'm trying to understand what the point of this bug is. > > Originally I thought it was that urjtag has no adapter list and wants > some udev rules for access and wanted to piggy back on OpenOCD's list.
Yes, correct. > Subsequently it sounds that while this might be part of the reason it is > additionally desired to just have a "list of JTAG adapter udev rules" > that do not correspond to either OpenOCD or urjtag but include aspects > of both. Incorrect. > I still don't understand why each package can't manage the pieces of > hardware that they support, instead of having a new very small package > that ultimately will require work on both sides to ensure it stays valid > for all adapters The "staying valid" is done upstream, not in Debian or it's devirates. > (rather than, say, just being able to be a copy of the > OpenOCD upstream list, if urjtag had been a strict subset). There is no reason for thinking in subsets. > There's no > issue with multiple udev rules files covering the same rule - the last > one will win and I'm assuming both packages will be adding them as > plugdev anyway so they'll be the same. In the same was as there is a > /lib/udev/rules.d/60-openocd.rules there can be a > /lib/udev/rules.d/60-urjtag.rules? It is the "last one will win" that should be avoided. A package with /lib/udev/rules.d/60-openocd.rules used by _both openocd and urjtag_ will prevent a fight about who is last. Groeten Geert Stappers P.S. In an ideal world, or on the long run, there would be an upstream project that collects all VID:PID of JTAG-adapters. -- Leven en laten leven
