+++ This bug was initially created as a clone of Bug #466041 +++ Note: I do not agree that hwdata is the proper place to carry this script, but the last close of the clones parent bug makes it clear that the usbutils maintainer does ... as such I open this clone Description of problem: usbutils-0.73 does not robustly package the updateing script from the usbutils tarball as a SOURCE1 ... +cp update-usbids.sh $RPM_BUILD_ROOT%{_sbindir} %files %defattr(-,root,root,-) +%{_sbindir}* --- Additional comment from jmoskovc on 2008-11-03 08:34:19 EDT --- Hi Herrold, thanks for your patch, but I don't think updating files that belong to some package is good idea other it's against RPM logic. Imagine if someone hacks the source you're downloading from and you download some evil script. It totally overrides all rpm security mechanism like checksums and package signing. The only clean way is to update hwdata and then install this updated package. --- Additional comment from jmoskovc on 2009-05-06 08:18:13 EDT --- (In reply to comment #8) > Add update-usbids.sh script to the package. > A script with the similar functionality is present in pciutils. Yes, it's present, but if user use it, it will break the hwdata rpm consintency. I'll fix the usbutils spec file according to proposed patch, but i won't add the update script to usbutils, if it should be in some rpm (which I doubt) it should be in hwdata rpm. --- Additional comment from lubek.net on 2009-05-06 08:53:25 EDT --- The /sbin or /usr/sbin directory selection depends on the Fedora rules and the application of LHS. lsusb (and also lspci) are probably expected to be in /sbin. I would not move it without at least asking other packagers. When seeing that the usbutils' author has removed the script from the package without a notice in the ChangeLog I do not object to your decision. It would still be good to provide such script or similar functionality to the user. --- Additional comment from herrold on 2009-05-06 10:28:36 EDT --- as to comment #9 great as to committing the spec delta -- thank you As to comment #9 and #10 as to doing data updates, I find that pci hwdata and usb-id's do not have any material cross dependencies, as they are separately maintained projects. I update either one of the other, when I add new devices in a given class, without issue. ymmv --- Additional comment from herrold on 2009-07-14 10:56:55 EDT --- Fixes still not in the latest (usbutils-0.82-3) ... HOW do I get this applied? --- Additional comment from jmoskovc on 2009-11-12 05:25:36 EDT --- I think I made my self clear in comment #9 - I won't add the script into the rpm for obvious reasons. ============================================================ I do not see anything obvious about not including a script which is part of one package remotely -- nothing compels one to run it, and it is useful as the usbutils maintainer at sourceforge has chimed in. Because jmoskovc will not add it, I request the addition of the usb updating in the package he has suggested by this bug -- Russ herrold
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
late 12 reporting (technically doring stabilization) and not addressed there this is properly considered in 13, and so moving back to RawHide
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
still needed in rawhide -- reassigning
hmm, I wonder why I've never seen this bugreport before, must have slipped through or I would have closed this much earlier. hwdata doesn't ship any scripts, just text databases which will be read by programs in other packages. That's intentional as hwdata is one of those packages that usually get updated at the very last moment in the development cycle. Any breakages in scripts won't get noticed until it is too late. I intend to keep it that way and won't include the update-usbids script. It belongs to usbutils similar to update-pciids and the pciutils package. I'm not even sure sure if update-usb/pciids need to to be shipped at all. And I don't agree with https://bugzilla.redhat.com/show_bug.cgi?id=466041#c8, nothing breaks if usb.ids or pci.ids are out of date, it's just the difference between 'unknown device' and some device name, nothing else.
I think it is improper for component owner to close a bug report when he/she believes it belongs to another component. It makes much more sense to just change to the proper component. I'm reopening and moving to the usbutils component as suggested above. It really makes a lot of sense to have that script easily accessible to users. If needed, there could be a warning printed about potential issues and how to recover from them. But updating ids is very useful trying to identify hardware. I'd say usb ids are much more important as one can often change USB devices where PCI devices are touched less often.
workaround: download http://www.linux-usb.org/usb.ids to /usr/share/hwdata/usb.ids
The upstream script is: https://github.com/gregkh/usbutils/blob/master/update-usbids.sh.in one needs to change @usbids@ to /usr/share/hwdata/usb.ids is desires to install the script to /usr/local/sbin Preferably we ship it as a script though.
I think this bug is getting a bit obsolete, usbutils now moves to use hwdd from systemd-udev https://github.com/gregkh/usbutils/commit/c6282a7a0e20fbb9c56837f055843635a43ba8b4 And also files in /usr/ are generally shiped by distribution and should not be altered by user. Maybe it could be overiden by some file placed in /etc/ but I don't see huge benefits in it.
I think that user should still have way to update hardware database... anyway.