[Pkg-electronics-devel] Bug#852856: what is the point of this bug

[Geert Stappers]

> 
> 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