On 25/09/2022 13:04, Aurelien Jarno wrote: >
- The debian policy forbids to install a script in /usr/bin with the .py extension. It can not be called lsusb given the existing binary already provided by usbutils.
Policy sec. 10.4 says "the script name should not include an extension"; it doesn't say "must not".
On policy's side, we have not wanting to necessarily expose users to the fact that a script is written in a particular language.
On the other hand, upstream ships the script with this name, other distributions (at least Fedora and RHEL) install it as lsusb.py and so users (me!) expect it to be called that. The options and output of the script are completely different to the traditional lsusb command, so I don't ever expect upstream to replace the traditional lsusb command with this script, or to rename it.
IMO this tips the balance in favour of shipping it as lsusb.py.
- lsusb.py needs python3 and the usb.ids database, so it increases the disk footprint from ~0.5MB to ~22.3MB which has a big impact for embedded systems.
lsusb.py is still useful without usb.ids: it still shows the USB bus topology, including information about which drivers are attached to which interface, without it (try running lsusb.py -f /blah -i). So I think a Suggests is appropriate.
As for Python 3, I think Suggests is also appropriate: 99% of my use of the script is "what new weird way has this laptop manufacturer chosen to hook up its built-in peripherals" and this is, for me, always done on a system where python3 and usb.ids are pulled in by something else anyway. On small-footprint systems, the addition of an lsusb.py script that doesnt't work unless you pull in python3 isn't a regression.
OTOH adding a binary package for this one small script is additional archive bloat. Those embedded systems will suffer a little bit more for the extra package they need to know about in /var/lib/apt/lists... ;)
- lsusb.py lacks a manpage.
I've just written one. :)
If lsusb.py is really way more useful than lsusb, an option might be to ship it in a separate package (usbutils-py? lsusb-py?) and change the binary name (lsusb-py? lsusb-python?).
If you think a trip through binNEW is worth it, lsusb-py would make sense to me. I've prepared a debian.tar.xz with this in mind, attached to this message for your consideration.
I've not renamed the command, but if the above doesn't convince you, how about /usr/bin/lsusb-py? (of course, the man page also has to be renamed, which makes it harder to send upstream...)
Cheers, -- Sam Morris <https://robots.org.uk/> PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
usbutils_014-1.1.debian.tar.xz
Description: Binary data
