On Wed, 29 Apr 2009, Kay Sievers wrote: > > Debian places it in /var/lib/usbids/ for a good reason. So does Ubuntu. > > Both have working "update-usbids" scripts (might be the one from upstream, > > or something different). They also have the original file in /usr/share, I > > don't know if usbutils was changed to check /var first then /usr, or what. > > Having several files on the same system sounds crazy from a distro > standpoint. There needs to be only a single database by default. Users We are talking about two files, here. Not several. > can do whatever they want anyway, but packages should not support such > a thing. If they are to be useful, yes, they do. Or do you want us to package just the usb-ids text file by itself and keep updating it all the time? That's the only other possibility, and it is done for the tzdata. But update-usbids (like update-pciids and update-intel-microcode) works just fine, so likely the usbutils maintainer didn't have any reasons to move from update-usbids to a volatile package. > If the user updates it, what does a new ids file do? Overwrite it Well, the package overwrites the older one if the download suceeds with a mv. No mess. If the download fails, the temp file is removed, and the older one remains untouched. There is no mess here. And it might be a simple case of the package creating /var/lib/usbids/usb.ids at post-install time from the static packaged data, and usbutils always using just /var/lib/usbids/usb.ids. I am not the maintainer of that package, and sincerely, given your tone, I am not inclined to go fetch the source and read the scripts. Now, I am not sure there is any checking against partial downloads. That is one thing a more controlled volatile package would be better at. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
