Re: usbutils 0.81 release

[Henrique de Moraes Holschuh]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/