[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: udev and /usr

On Fri, 04 Sep 2009, Marco d'Itri wrote:
> On Sep 04, Ron Johnson <ron.l.johnson@cox.net> wrote:
> > Whatever the cause, it breaks the FHS.
> Since it keeps being repeated, it is time to destroy this argument.
> FHS documents what distributions want to do: of the other relevant
> distributions, representatives from Red Hat and Suse said they do not
> support this and except Debian nobody else raised the issue.

RedHat doesn't care because RedHat users have to reinstall from scratch
every major version bump, which is equivalent to Debian telling you you have
to reinstall from scratch every new stable release.

So why exactly should we support this breakage in udev, again?  If what it
takes is to move the usb and pci ID databases to /, so be it.  When compared
to our kernel tarballs, they're small, less than 1MB for both of them.

As for the update-usbids and update-pciids problems, we can certainly
repackage this stuff in volatile and drop the two utilities as well the /var
issue it generates.  Symlinks will provide all backwards-compatibility that
is needed.  I believe we should do this regardless, but we better decide if
these databases have to live under / or /usr first.

How wise is to depend on these two databases for by-id symlinks, though?  I
have seen devices in my systems get new names and revised names on both PCI
and USB in the past, and I am not aware of any new rule that it won't happen
again.  There is also the obvious one when a device gets first added to the

IMO, whomever came up with the idea of leaking pci.ids and usb.ids data to
/dev, made a bad mistake.  Just because you'd show something in an UI,
doesn't mean it can be used to permanently identify a device safely.  I have
no idea what HAL, and HAL-consumers did with that information (maybe it was
for display purposes only, for example?), but I do know that stuff that ends
up in /dev/by-id IS very likely to be used as a permanent way to identify
devices in places like /etc/fstab, etc.

  "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

Reply to: