On Mon, Mar 12, 2018 at 11:13:10PM +0100, Geert Stappers wrote: > > I'm not sure that's entirely appropriate. You can perfectly easily add > > some udev rules to urjtag, rather than expecting openocd to solve the > > problem for you. It can even be done in a way that means the 2 packages > > can co-exist. #852856 is a wishlist bug that essentially says "we do the > > same thing, I'd like to take advantage of the work you've already done > > rather than maintaining a similar list myself". > > In my words: > > Avoiding duplicate work. > > My plan: > > Applying the patches, become stakeholder of openocd package. > Working together.
If you want to work together you have to have a discussion. I appreciate the bug has been languishing without a response but it pre-dates my involvement with the OpenOCD package and it's not been as high priority as getting the package up to date with upstream or dealing with security issues. On Mon, Mar 12, 2018 at 11:13:26PM +0100, Geert Stappers wrote: > On Mon, Mar 12, 2018 at 09:39:29AM +0000, Jonathan McDowell wrote: > > Is there a direct 1:1 mapping of devices that OpenOCD and urjtag > > support, or is one a subset of the other? > > Seen the question, but I don't see where it fits in the discussion > about a openocd file moving into seperate package. If one program is a strict subset of the other in terms of supported adaptors then it may make sense for the program with the larger support matrix to split a file out so that the other can take advantage of it. If the 2 programs support different adaptors then I'm not sure of the benefit; it becomes extra work on both parts to maintain the overlapping list? J. -- Avoid GOTOs completely if you can keep the program readable. This .sig brought to you by the letter L and the number 49 Product of the Republic of HuggieTag