Re: udev and /usr
On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote: From what I can see in /lib/udev/rules.d, the ids files are only used to setup the (udev) environment variable ID_VENDOR_FROM_DATABASE (75-net-description.rules, 75-tty-description.rules, 78-sound-card.rules). There are no symlinks created in /dev based on that information. Given the name of the rules file, it indeed looks to be intended to be used for display/descriptive purposes. So, again, why can't the programs that want to display this do the lookup themselves? Both libpciaccess and libpci provide API for this as far as I can tell. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
Julien Cristau wrote: On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote: From what I can see in /lib/udev/rules.d, the ids files are only used to setup the (udev) environment variable ID_VENDOR_FROM_DATABASE (75-net-description.rules, 75-tty-description.rules, 78-sound-card.rules). There are no symlinks created in /dev based on that information. Given the name of the rules file, it indeed looks to be intended to be used for display/descriptive purposes. So, again, why can't the programs that want to display this do the lookup themselves? Both libpciaccess and libpci provide API for this as far as I can tell. I am sure, they could. My guess is, it was added to udev to make porting apps from HAL to lib(g)udev easier and more convenient as you only have one API to write against (as you had with HAL) To get the information from pci.ids/usb.ids, you'd need to link to both libpci (and libusb, I guess) and write different code for the usb and pci case. A char *vendor = g_udev_device_get_property (device, ID_VENDOR_FROM_DATABASE); is certainly a lot easier. But that is just guessing. Maybe we should simply ask udev upstream (CCed) @Kay: the start of the discussion is at [1] Cheers, Michael [1] http://lists.debian.org/debian-devel/2009/09/msg2.html -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: udev and /usr
Le lundi 07 septembre 2009 à 17:29 +0200, Michael Biebl a écrit : So, again, why can't the programs that want to display this do the lookup themselves? Both libpciaccess and libpci provide API for this as far as I can tell. I am sure, they could. My guess is, it was added to udev to make porting apps from HAL to lib(g)udev easier and more convenient as you only have one API to write against (as you had with HAL) To get the information from pci.ids/usb.ids, you'd need to link to both libpci (and libusb, I guess) and write different code for the usb and pci case. A char *vendor = g_udev_device_get_property (device, ID_VENDOR_FROM_DATABASE); is certainly a lot easier. Wouldn’t it be possible to let libgudev itself do the job? OTOH it would then link to libpci and libusb, but that may be a better solution. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: udev and /usr
On Mon, 07 Sep 2009, Julien Cristau wrote: On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote: From what I can see in /lib/udev/rules.d, the ids files are only used to setup the (udev) environment variable ID_VENDOR_FROM_DATABASE (75-net-description.rules, 75-tty-description.rules, 78-sound-card.rules). There are no symlinks created in /dev based on that information. Oh yes, there are. Either Unstable's udev or something else does this for USB at the very least. Noticed it when playing with a Huawei E220 HSDPA USB modem, the usb.ids information ended up in /dev/serial/by-id. Here's the proof (output edited for brevity): khazad-dum:~$ lsusb ; ls -l /dev/serial/by-id/* Bus 004 Device 003: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA Modem / E270 HSDPA/HSUPA Modem lrwxrwxrwx 1 root root 13 2009-09-07 14:56 /dev/serial/by-id/usb-HUAWEI_Technologies_HUAWEI_Mobile-if00-port0 - ../../ttyUSB0 lrwxrwxrwx 1 root root 13 2009-09-07 14:56 /dev/serial/by-id/usb-HUAWEI_Technologies_HUAWEI_Mobile-if01-port0 - ../../ttyUSB1 Now, I am not claiming it it is not useful. However, IMO it would be useful *and* safe if I had a by-id link using the proper USB ID *numbers* instead, which I could use on /etc/ppp/peers/* for example. -- 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, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
Henrique de Moraes Holschuh wrote: On Mon, 07 Sep 2009, Julien Cristau wrote: On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote: From what I can see in /lib/udev/rules.d, the ids files are only used to setup the (udev) environment variable ID_VENDOR_FROM_DATABASE (75-net-description.rules, 75-tty-description.rules, 78-sound-card.rules). There are no symlinks created in /dev based on that information. Oh yes, there are. Either Unstable's udev or something else does this for USB at the very least. Noticed it when playing with a Huawei E220 HSDPA USB modem, the usb.ids information ended up in /dev/serial/by-id. Could you investigate which udev rules file does that? The files I mentioned above clearly don't and I haven't found any other rules file on my laptop which either used pci-db/usd-db or ID_VENDOR_FROM_DATABASE. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: udev and /usr
On Mon, Sep 07, 2009 at 02:59:44PM -0300, Henrique de Moraes Holschuh wrote: On Mon, 07 Sep 2009, Julien Cristau wrote: On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote: From what I can see in /lib/udev/rules.d, the ids files are only used to setup the (udev) environment variable ID_VENDOR_FROM_DATABASE (75-net-description.rules, 75-tty-description.rules, 78-sound-card.rules). There are no symlinks created in /dev based on that information. Oh yes, there are. Either Unstable's udev or something else does this for USB at the very least. Noticed it when playing with a Huawei E220 HSDPA USB modem, the usb.ids information ended up in /dev/serial/by-id. The changes in question aren't even in unstable yet. So something else must be to blame. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: udev and /usr
On Mon, 07 Sep 2009, Steve Langasek wrote: On Mon, Sep 07, 2009 at 02:59:44PM -0300, Henrique de Moraes Holschuh wrote: On Mon, 07 Sep 2009, Julien Cristau wrote: On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote: From what I can see in /lib/udev/rules.d, the ids files are only used to setup the (udev) environment variable ID_VENDOR_FROM_DATABASE (75-net-description.rules, 75-tty-description.rules, 78-sound-card.rules). There are no symlinks created in /dev based on that information. Oh yes, there are. Either Unstable's udev or something else does this for USB at the very least. Noticed it when playing with a Huawei E220 HSDPA USB modem, the usb.ids information ended up in /dev/serial/by-id. The changes in question aren't even in unstable yet. So something else must be to blame. Ok. I am trying to track it down. -- 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, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Mon, Sep 7, 2009 at 14:59:44 -0300, Henrique de Moraes Holschuh wrote:
khazad-dum:~$ lsusb ; ls -l /dev/serial/by-id/*
Bus 004 Device 003: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA
Modem / E270 HSDPA/HSUPA Modem
lrwxrwxrwx 1 root root 13 2009-09-07 14:56
/dev/serial/by-id/usb-HUAWEI_Technologies_HUAWEI_Mobile-if00-port0 -
../../ttyUSB0
lrwxrwxrwx 1 root root 13 2009-09-07 14:56
/dev/serial/by-id/usb-HUAWEI_Technologies_HUAWEI_Mobile-if01-port0 -
../../ttyUSB1
60-persistent-serial.rules from sid's udev:
IMPORT=usb_id --export %p
ENV{ID_SERIAL}==, GOTO=persistent_serial_end
SUBSYSTEMS==usb, ENV{ID_IFACE}=$attr{bInterfaceNumber}
ENV{ID_IFACE}==, GOTO=persistent_serial_end
ENV{ID_PORT}==,
SYMLINK+=serial/by-id/$env{ID_BUS}-$env{ID_SERIAL}-if$env{ID_IFACE}
ENV{ID_PORT}==?*,
SYMLINK+=serial/by-id/$env{ID_BUS}-$env{ID_SERIAL}-if$env{ID_IFACE}-port$env{ID_PORT}
Cheers,
Julien
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Mon, 07 Sep 2009, Steve Langasek wrote: On Mon, Sep 07, 2009 at 02:59:44PM -0300, Henrique de Moraes Holschuh wrote: On Mon, 07 Sep 2009, Julien Cristau wrote: On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote: From what I can see in /lib/udev/rules.d, the ids files are only used to setup the (udev) environment variable ID_VENDOR_FROM_DATABASE (75-net-description.rules, 75-tty-description.rules, 78-sound-card.rules). There are no symlinks created in /dev based on that information. Oh yes, there are. Either Unstable's udev or something else does this for USB at the very least. Noticed it when playing with a Huawei E220 HSDPA USB modem, the usb.ids information ended up in /dev/serial/by-id. The changes in question aren't even in unstable yet. So something else must be to blame. Found them on /lib/udev. This is in udev 141. There is /lib/udev/usb_id, and /lib/udev/60-persistent-serial (and a few other scripts in there) that use usb_id to make symlinks. A quick look at the usb_id source tells me aparently there is NOTHING WRONG with it. It doesn't seem to use usb.ids, just whatever information the kernel provides from the device (and device driver) knowledge about itself, which is a lot more static than usb.ids, and protected by the kernel stable ABI rules. So, I am _happy_ to correct myself and state that currently, usb.ids information is NOT used anywhere by udev scripts I know of. -- 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, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Sun, 2009-09-06 at 05:01 +0200, Marco d'Itri wrote: On Sep 06, Steve Langasek vor...@debian.org wrote: It's normal that in the process of drafting a standard, people will take into account the prevailing real-world practices, to ensure that the standard will be useful. Once something *is a standard*, you don't arbitrarily change what you're doing and claim that it still complies with the standard because the standard follows what Red Hat does. I am not claiming that this complies with the standard, just that it does not matter because if there is a wide consensus (which does not need to be unanimous) about this then eventually the standard will be updated to reflect it. Anyway, FHS also has examples of things changed long after they were adopted by everybody, like /var/spool/mail/ vs. /var/mail/. I would ask a question to [FHS|udev-upstream|whoever] : What smooth migration path do you offer for those millions systems that are installed with a standalone /usr? I am grateful to udev developers and maintainers. I remember what was Linux before udev... (far too many vim /etc/modules, MAKEDEV, chown and chmod ) FWIW, I did some statistics on installation-reports (in my debian-boot mailing list backlog). 48 reports has the string % /dev 18 reports has the string % /usr That's 37% ! This statistics are probably biased, because people with a single partition layout probably don't bother reporting their disk partitioning. My 2¢, Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Fri, 04 Sep 2009, Marco d'Itri wrote: On Sep 04, Ron Johnson ron.l.john...@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 database. 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
Henrique de Moraes Holschuh wrote: 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. Agreed. Moving usb.ids and pci.ids to / (/lib/hwdata was a proposed location) seems currently the best solution to me. 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. I'd also vote for removing update-usbids and update-pciids. Those tools looks broken to me anyway. given that a package upgrade will overwrite an updated ids file again. Aurel's concern was, if usbutils (and pciutils for that matter) were acceptable for volatile and Luk (on debian-release) acknowledged that this package would be ok for volatile and stable point releases. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: udev and /usr
On Mon, 07 Sep 2009, Michael Biebl wrote: Henrique de Moraes Holschuh wrote: 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. Agreed. Moving usb.ids and pci.ids to / (/lib/hwdata was a proposed location) seems currently the best solution to me. Well, the best solution could well be to not do fragile, broken things like using variable (and untrusted) data to set up permanent device ids. So, I'd rather see that one answered before anyone bothers with moving pci.ids and usb.ids around. -- 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, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
Henrique de Moraes Holschuh wrote: 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. From what I can see in /lib/udev/rules.d, the ids files are only used to setup the (udev) environment variable ID_VENDOR_FROM_DATABASE (75-net-description.rules, 75-tty-description.rules, 78-sound-card.rules). There are no symlinks created in /dev based on that information. Given the name of the rules file, it indeed looks to be intended to be used for display/descriptive purposes. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: udev and /usr
sean finney sean...@debian.org writes: On Tue, Sep 01, 2009 at 03:01:35PM +0200, Giacomo A. Catenazzi wrote: Jonas Meurer wrote: do we really consider to stop support for seperate /usr? after all fhs supports seperate /usr by design. [1] i hope that we keep fhs compability within debian. I agree, but the problem is how?. i make no claims about the on-crackiness of the following suggestion, but: what about smuggling such precious and required files into the initrd, and either copying them at boot time or having a temporary bind-mount to make them available until the real /usr can take over? sean Bind mount / to /real-root/ and install them to /real-root/usr/... as well as /usr/... That at least would be doable without breaking existing systems or forcing an imho bad partitioning on people. Like many people I have a small / partition (as raid1) and everything else in lvm. The size of / is relatively constant and I have plenty of breathing space there (still 40% free). The size of /usr on the other hand greatly varries depending on installed software and grows a lot over time, needs resizes. / must be outside LVM for so many reasons and /usr must be on lvm. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
Josselin Mouette j...@debian.org writes: Le mardi 01 septembre 2009 à 10:32 +0200, Petter Reinholdtsen a écrit : In Debian, /usr/ is allowed to be on NFS. So is /. Mounting NFS volumes from the initramfs is probably not worth the effort. How do you make root on NFS work without this? By building a kernel with nfsroot support and mounting without locking and specific nfs version. I'm not sure if initramfs also supports it but I would rather doubt it can build an initramfs with nfs support on its own. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
Petter Reinholdtsen p...@hungry.com writes: [Bastian Blank] Why do you not extend the current setup to do another step? Currently we have two - in the initramfs with only minimal information and - during the rcS run with / available. Eh, currently we have 5 sections during the boot: - initramfs with minimal set of files available. - rcS with only / available read-only (before checkroot.sh) Migth never happen. And since you can't rely on it ever happening you can just as well assume it never happens. Just ignore if / becomes read-write. - rcS with / read-write, /var/ and /usr/ might be missing (after checkroot.sh) - rcS with / and /var/ read-write (after mountall.sh) - rcS with /, /var/ and /usr/ read-write (after mountnfs.sh) /usr might also never be read-write. But it might be missing at first. I don't realy see that there is an explicit stage where we have /var but not /usr. There is a stage where local filesystems are mounted and one where networking filesystems get mounted. But both /var and /usr could be local or networked. Everything running during boot need to know which section it is running it, and avoid using tools and files only guaranteed to be available in later sections. In addition, there is an optional section split when udev is installed after / is read-only and before it is read-write, which is before and after devices in /dev/ are available. In runlevels 2-5 local and NFS file systems are available, so scripts running from there can be a less carefyl Happy hacking, -- Petter Reinholdtsen Just splitting into initramfs, only / read-only and everything seems sufficient. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On 2009-09-05, Goswin von Brederlow goswin-...@web.de wrote: Mounting NFS volumes from the initramfs is probably not worth the effort. How do you make root on NFS work without this? By building a kernel with nfsroot support and mounting without locking and specific nfs version. I'm not sure if initramfs also supports it but I would rather doubt it can build an initramfs with nfs support on its own. See /usr/share/initramfs-tools/scripts/nfs. (If I understood your concerns correctly; I'm doing NFS root with an initrd created by initramfs just fine.) Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Sep 05, Steve Langasek vor...@debian.org wrote: They are currently providing most of the manpower for developing udev and the related infrastructure so this is pretty much the practical effect, yes. So what, you think this means we don't have any right to object when they design things wrong? No, I mean that after objecting and failing to have my objections accepted, I have no other means of steering development in a different direction. I objected, multiple times, alone, and then started a discussion here. What did *you* do other than accusing me? Violating the FHS is incompetent by definition and any resulting design is unreliable. Maybe you were not involved with FSSTND and FHS development at the time, but in multiple occasions it was modified to reflect what distributions actually wanted to implement of previous versions of the specification, like when /usr/libexec and /var/state were added and then removed again (it was about 1997). I was following FHS development at the time and I remember it. That bug was reopened as a result of a conversation I had with Martin and Scott in response to this precise thread. I was hoping Scott would be able to shed some light on the motivation for this goofy design, but he was just as much in the dark regarding the reason this was added and wasn't aware of the FHS problem that had been introduced. But he was aware of other /usr-related issues in udev, and his answer was that Ubuntu does not support standalone /usr filesystems. Do you have a reference to a thread where someone upstream has acknowledged the existence of this FHS bug and proceeded to implement this anyway? There was at least http://article.gmane.org/gmane.linux.hotplug.devel/14384 , but most discussions happened on IRC where everybody else involved explained in no uncertain terms that they do not want to support a standalone /usr filesystem. You most certainly are arguing for a side, and it's not for the side that you have an obligation to as a Debian developer. I love when people know what I think better than I do... -- ciao, Marco signature.asc Description: Digital signature
Re: udev and /usr
On Sun, Sep 06, 2009 at 12:56:03AM +0200, Marco d'Itri wrote: They are currently providing most of the manpower for developing udev and the related infrastructure so this is pretty much the practical effect, yes. So what, you think this means we don't have any right to object when they design things wrong? No, I mean that after objecting and failing to have my objections accepted, I have no other means of steering development in a different direction. If you're unable to persuade upstream to change their implementation, and you're unwilling to diverge from upstream to ensure the package complies with Debian policy, your other option is to orphan the package and let someone maintain it who is willing to ensure it complies with Debian Policy. I don't mean to imply that this last is what you should do; I'm merely pointing out the set of options at your disposal. And pointing out that shipping a package that violates Debian Policy in such a blatant manner isn't one of those options. I objected, multiple times, alone, and then started a discussion here. What did *you* do other than accusing me? I appreciate that you took the time to bring this issue to the project's attention. What I don't appreciate is your statement that you don't intend to do anything about it (there's a policy violation, one of your packages is involved; it's your responsibility as a maintainer to help find a solution), or your claims that we shouldn't care about FHS compliance if Red Hat and SuSE don't. As for me, what I am doing is making sure I have all the facts so that I can take this issue upstream as you suggested. Violating the FHS is incompetent by definition and any resulting design is unreliable. Maybe you were not involved with FSSTND and FHS development at the time, but in multiple occasions it was modified to reflect what distributions actually wanted to implement of previous versions of the specification, like when /usr/libexec and /var/state were added and then removed again (it was about 1997). I was following FHS development at the time and I remember it. I am familiar with the history of the FHS. It's normal that in the process of drafting a standard, people will take into account the prevailing real-world practices, to ensure that the standard will be useful. Once something *is a standard*, you don't arbitrarily change what you're doing and claim that it still complies with the standard because the standard follows what Red Hat does. The FHS as part of Debian Policy is a promise to our users that they can rely on the system working a certain way. It's not ok for *any* upstream to force us to break that promise, no matter how important they think they are. That bug was reopened as a result of a conversation I had with Martin and Scott in response to this precise thread. I was hoping Scott would be able to shed some light on the motivation for this goofy design, but he was just as much in the dark regarding the reason this was added and wasn't aware of the FHS problem that had been introduced. But he was aware of other /usr-related issues in udev, and his answer was that Ubuntu does not support standalone /usr filesystems. Do you have a pointer to where he said this, or was this another unlogged IRC discussion? The last time you made this claim, I asked Scott about it and he denied that this was his position. Given that there has quite specifically been work put into making /usr-on-a-separate-filesystem work in Ubuntu in the last release cycle (work that unfortunately has been undone to some degree by devicekit without anyone noticing until now), I would like to make sure we do have a shared understanding of how this is supposed to work, but it's hard to do this when all I have is hearsay. Do you have a reference to a thread where someone upstream has acknowledged the existence of this FHS bug and proceeded to implement this anyway? There was at least http://article.gmane.org/gmane.linux.hotplug.devel/14384 , but most discussions happened on IRC where everybody else involved explained in no uncertain terms that they do not want to support a standalone /usr filesystem. Ok, thanks for the reference. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: udev and /usr
On Sep 06, Steve Langasek vor...@debian.org wrote: If you're unable to persuade upstream to change their implementation, and you're unwilling to diverge from upstream to ensure the package complies with Debian policy, your other option is to orphan the package and let I am willing to diverge from upstream and I have been doing it in varying degrees for the whole like of the package, what I am unwilling to do is to adopt crazy solutions which are broken, unmaintenable and/or useless anyway in the long end. It's normal that in the process of drafting a standard, people will take into account the prevailing real-world practices, to ensure that the standard will be useful. Once something *is a standard*, you don't arbitrarily change what you're doing and claim that it still complies with the standard because the standard follows what Red Hat does. I am not claiming that this complies with the standard, just that it does not matter because if there is a wide consensus (which does not need to be unanimous) about this then eventually the standard will be updated to reflect it. Anyway, FHS also has examples of things changed long after they were adopted by everybody, like /var/spool/mail/ vs. /var/mail/. The FHS as part of Debian Policy is a promise to our users that they can rely on the system working a certain way. It's not ok for *any* upstream to force us to break that promise, no matter how important they think they are. While it is not OK, it is also hard to avoid. The last time you made this claim, I asked Scott about it and he denied that this was his position. Given that there has quite specifically been And I am pretty much sure that he told me otherwise, but I do not think this is very important now: if Ubuntu really has a policy of supporting a standalone /usr then it's about time that the Ubuntu developers join the relevant discussions on IRC and/or the linux-hotplug mailing list and show that Debian is not alone. -- ciao, Marco signature.asc Description: Digital signature
Re: udev and /usr
On Fri, Sep 04, 2009 at 12:59:10AM -0400, Felipe Sateler wrote:
The issue was raised by the udev upstream maintainer along with the udev
package maintainers of the major distributions, who all agreed that this
configuration is not supported.
FYI, udev 146 ships usb-id and pci-id programs which read
/usr/share/misc/usb.ids and /usr/share/misc/pci.ids .
udev itself does not care about the results of these programs but other
programs which used to use HAL may do, leading to subtle breakage.
Reading again your mail, I think we are discussing a inexistent problem.
You say that some programs which use HAL may do use /usr/share.
Hal also lives on /usr, so I don't see the problem either.
The problem is this:
- In udev 146 and above, a number of the stock udev rules call the
/lib/udev/{pci,usb}-db helpers to query the vendor name / product name
and and this information to the udev environment.
- These helpers work by parsing the pci.ids and usb.ids databases, which
have long had standard locations that are *not* in /lib (either in /usr
or in /var, both of which are allowed to be separate filesystems under
the FHS).
- Now that there are udev rules exporting this information, arbitrary other
components in the stack may come to rely on this information being
available (but we don't seem to know what components; the rationale for
this facility being added to udev so far is pretty opaque, though
whatever it is can't be good).
- These udev rules are applied from runlevel S, before /usr or /var are
guaranteed to be mounted. That means that any device which is detected
by the kernel before this point (such as non-hotpluggable PCI devices)
will have different information exported by udev depending on whether
/usr and /var are on the root filesystem.
I still can't fathom why someone decided that udev should be responsible for
translating PCI IDs and USB IDs into text strings. This smells of crazy.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Re: udev and /usr
Steve Langasek wrote:
On Fri, Sep 04, 2009 at 12:59:10AM -0400, Felipe Sateler wrote:
The issue was raised by the udev upstream maintainer along with the udev
package maintainers of the major distributions, who all agreed that this
configuration is not supported.
FYI, udev 146 ships usb-id and pci-id programs which read
/usr/share/misc/usb.ids and /usr/share/misc/pci.ids .
udev itself does not care about the results of these programs but other
programs which used to use HAL may do, leading to subtle breakage.
Reading again your mail, I think we are discussing a inexistent problem.
You say that some programs which use HAL may do use /usr/share.
Hal also lives on /usr, so I don't see the problem either.
The problem is this:
- In udev 146 and above, a number of the stock udev rules call the
/lib/udev/{pci,usb}-db helpers to query the vendor name / product name
and and this information to the udev environment.
- These helpers work by parsing the pci.ids and usb.ids databases, which
have long had standard locations that are *not* in /lib (either in /usr
or in /var, both of which are allowed to be separate filesystems under
the FHS).
- Now that there are udev rules exporting this information, arbitrary other
components in the stack may come to rely on this information being
available (but we don't seem to know what components; the rationale for
this facility being added to udev so far is pretty opaque, though
whatever it is can't be good).
- These udev rules are applied from runlevel S, before /usr or /var are
guaranteed to be mounted. That means that any device which is detected
by the kernel before this point (such as non-hotpluggable PCI devices)
will have different information exported by udev depending on whether
/usr and /var are on the root filesystem.
I still can't fathom why someone decided that udev should be responsible for
translating PCI IDs and USB IDs into text strings. This smells of crazy.
I agree, also considering that AFAIK we have not the official names, thus from
time to time there are huge renames in the ids files. Sometime a company
changes the name and the ids file will change (addition or change of suffix
like limited etc; adding or replacing the new company name (on merges), ...
Some names contain non alphanumeric characters, which is annoying on device
names (they are properly quoted, but anyway).
Thus the use of ids file create not stable device names, and probably not
nice names. I really think numeric names are a lot better.
Anyway reading the id_usb:
* A unique USB identification is generated like this:
*
* 1.) Get the USB device type from InterfaceClass and InterfaceSubClass
* 2.) If the device type is 'Mass-Storage/SPC-2' or 'Mass-Storage/RBC'
* use the SCSI vendor and model as USB-Vendor and USB-model.
* 3.) Otherwise use the USB manufacturer and product as
* USB-Vendor and USB-model. Any non-printable characters
* in those strings will be skipped; a slash '/' will be converted
* into a full stop '.'.
* 4.) If that fails, too, we will use idVendor and idProduct
* as USB-Vendor and USB-model.
* 5.) The USB identification is the USB-vendor and USB-model
* string concatenated with an underscore '_'.
* 6.) If the device supplies a serial number, this number
* is concatenated with the identification with an underscore '_'.
Thus the use of name is only the third priority, and there are
3 additional fallbacks. Thus, IMHO, we don't need to worry much about
missing /usr/share on *some* environments.
Thus I think people who want a separate /usr can live lovely without
ids files (and probably they/me prefer numeric ids).
BTW the files are also included in the kernel, so we can use kernel
informations.
ciao
cate
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
Steve Langasek vor...@debian.org writes:
I still can't fathom why someone decided that udev should be responsible for
translating PCI IDs and USB IDs into text strings. This smells of crazy.
Yes. Any device specific matching should use vid:pid. How about just
disabling the /lib/udev/{pci,usb}-db helpers alltogether to avoid ever
getting any users of this info in Debian? It will always be too
unreliable to be useful anyway, regardless of /usr availability.
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Sep 04, Steve Langasek vor...@debian.org wrote:
I still can't fathom why someone decided that udev should be responsible for
translating PCI IDs and USB IDs into text strings. This smells of crazy.
I think that part of the rationale is that eventually HAL will go away
replaced by udev and programs like this (e.g. look at the keyboard stuff).
On Sep 04, Bjørn Mork bj...@mork.no wrote:
Yes. Any device specific matching should use vid:pid. How about just
disabling the /lib/udev/{pci,usb}-db helpers alltogether to avoid ever
getting any users of this info in Debian? It will always be too
unreliable to be useful anyway, regardless of /usr availability.
So you believe that the upstream maintainers are incompetent and
released something which is unreliable by design?
--
ciao,
Marco
signature.asc
Description: Digital signature
Re: udev and /usr
On Fri, Sep 4, 2009 at 11:41:41 +0200, Marco d'Itri wrote:
On Sep 04, Steve Langasek vor...@debian.org wrote:
I still can't fathom why someone decided that udev should be responsible for
translating PCI IDs and USB IDs into text strings. This smells of crazy.
I think that part of the rationale is that eventually HAL will go away
replaced by udev and programs like this (e.g. look at the keyboard stuff).
Former hal users will still be able to look stuff up in {usb,pci}.ids,
udev doesn't have to do it for them.
Cheers,
Julien
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
m...@linux.it (Marco d'Itri) writes:
On Sep 04, Bjørn Mork bj...@mork.no wrote:
Yes. Any device specific matching should use vid:pid. How about just
disabling the /lib/udev/{pci,usb}-db helpers alltogether to avoid ever
getting any users of this info in Debian? It will always be too
unreliable to be useful anyway, regardless of /usr availability.
So you believe that the upstream maintainers are incompetent and
No, I do not think they are incompetent. I think they have a hard job
trying to port features from hal to udev-extras without repeating all
the mistakes. I realize that hal have many users who presumably are
wanting to push all interfaces they use into udev.
released something which is unreliable by design?
Do /lib/udev/{pci,usb}-db provide any reliable additional information?
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Fri, Sep 04, 2009 at 11:41:41AM +0200, Marco d'Itri wrote: So you believe that the upstream maintainers are incompetent and released something which is unreliable by design? Incompetent, no. Careless, yes. Just think about the udev-related breakages in the past. And speaking about design, udev was originally praised because it can do everything in user space. Now, the authors of udev are proposing devtmpfs, because as it turned out, it's not _so_ rosy doing everything in userspace. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Sep 04, Gabor Gombas gomb...@sztaki.hu wrote: Incompetent, no. Careless, yes. Just think about the udev-related breakages in the past. And speaking about design, udev was originally praised because it can do everything in user space. Now, the authors of udev are proposing devtmpfs, because as it turned out, it's not _so_ rosy doing everything in userspace. What we have is the result of gradual evolution. People who can make accurate predictions 10 years into the future typically don't develop software. -- Wietse Venema on some aspects of postfix -- ciao, Marco signature.asc Description: Digital signature
Re: udev and /usr
On 2009-09-04 07:46, Marco d'Itri wrote: On Sep 04, Gabor Gombas gomb...@sztaki.hu wrote: Incompetent, no. Careless, yes. Just think about the udev-related breakages in the past. And speaking about design, udev was originally praised because it can do everything in user space. Now, the authors of udev are proposing devtmpfs, because as it turned out, it's not _so_ rosy doing everything in userspace. What we have is the result of gradual evolution. People who can make accurate predictions 10 years into the future typically don't develop software. -- Wietse Venema on some aspects of postfix Whatever the cause, it breaks the FHS. I'd not call it incompetent or careless. Rather... narrow sighted and un-Unixy. Too PC-ish. Someone should have remembered that there are times when separate /usr and /var is A Good Thing. -- Brawndo's got what plants crave. It's got electrolytes! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Tue, Sep 01, 2009 at 05:24:19AM +0200, Marco d'Itri wrote: FYI, udev 146 ships usb-id and pci-id programs which read /usr/share/misc/usb.ids and /usr/share/misc/pci.ids . udev itself does not care about the results of these programs but other programs which used to use HAL may do, leading to subtle breakage. Why do you not extend the current setup to do another step? Currently we have two - in the initramfs with only minimal information and - during the rcS run with / available. You could just add another (change) trigger run after all filesystems are available. (Okay, this extra names must not be used in the fstab at all then.) Bastian -- Intuition, however illogical, is recognized as a command prerogative. -- Kirk, Obsession, stardate 3620.7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Sep 04, Ron Johnson ron.l.john...@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. I should stress that this is not related in any way to the merit of supporting a standalone /usr, but if most distributions do not care about it then it is FHS which needs to be fixed. -- ciao, Marco signature.asc Description: Digital signature
Re: udev and /usr
On Sep 04, Bastian Blank wa...@debian.org wrote: Why do you not extend the current setup to do another step? Currently we Even if this were possible at all, it would require (for a start): - working out all the possible side effects of synthesizing all/most (which ones?) events a second time - having to forward port these changes forever, with the possibility of a new architectural change making the exercise useless at any time This is a development albatross which I do not need, and Debian neither. You could just add another (change) trigger run after all filesystems are available. (Okay, this extra names must not be used in the fstab at all then.) No reason to bother then, persistent names are indispensable for many non-trivial systems. -- ciao, Marco signature.asc Description: Digital signature
Re: udev and /usr
m...@linux.it (Marco d'Itri) writes: On Sep 04, Ron Johnson ron.l.john...@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. The issue is most certainly raised by other distributions. See e.g. the thread starting with http://article.gmane.org/gmane.linux.gentoo.devel/62973 But I guess Red Hat and Suse decide. Debian does what they do, nobody cares about Gentoo, and Ubuntu does what Debian does. No, wait, they don't: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/372241 I should stress that this is not related in any way to the merit of supporting a standalone /usr, but if most distributions do not care about it then it is FHS which needs to be fixed. Either you follow the FHS or you don't. You seem to argue that most distributions don't and that Debian therefore shouldn't either. That's sad. Please fix the FHS first if you think it should be fixed. Or leave it alone and fix udev instead. Personally I really can't see why these addons (usb-db,pci-db) are so important. Nobody has demonstrated a usecase for them. Yet you make it sound like there is no choice at all, but to include them in udev. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
Bjørn Mork wrote: Personally I really can't see why these addons (usb-db,pci-db) are so important. Nobody has demonstrated a usecase for them. Yet you make it sound like there is no choice at all, but to include them in udev. Seconded. The Debian 5 system I just built (2.6.29 kernel from backports) has the files mentioned under /usr/share linked to /var/lib as described; /, /usr and /var/lib are all separate filesystems and it boots just dandy. Is there anything in these files that's actually needed before we get to the point where /usr can be assumed to have mounted, barring major errors? If so, what? Personally it'd be a nuisance if I can't put /usr onto a separate partition, and a major headache if I can't split /var off - there're spools and databases and all sorts of things in there where if something runs away I'd rather it ran just that filesystem out of space rather than killing the whole server. But, I'm looking at servers where all that's required are discs and network. Could it be any additional ids required are for more exotic hardware unlikely to be encountered in such a scenario? If it were the case that for some exotics you have to have bits of /usr and /var on the same partition as / I guess that would be liveable. Just a thought. -- Chris Jackson Shadowcat Systems Ltd. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Sep 04, Bjørn Mork bj...@mork.no wrote: The issue is most certainly raised by other distributions. See e.g. the thread starting with http://article.gmane.org/gmane.linux.gentoo.devel/62973 This is about the micromanagement of dependencies which greatly excites Gentoo users, so is not very relevant (and Gentoo itself is hardly relevant anyway). But I guess Red Hat and Suse decide. Debian does what they do, nobody They are currently providing most of the manpower for developing udev and the related infrastructure so this is pretty much the practical effect, yes. cares about Gentoo, and Ubuntu does what Debian does. No, wait, they don't: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/372241 This may become an interesting development, but it is not consistent with the behaviour so far of the Canonical employees involved in the development of udev. Either you follow the FHS or you don't. You seem to argue that most distributions don't and that Debian therefore shouldn't either. That's sad. Please fix the FHS first if you think it should be fixed. Or leave it alone and fix udev instead. Actually I am carefully avoiding to argue for either side, and trying to provide useful facts instead. On your part, you could try to understand them instead of attributing to me straw man positions. -- ciao, Marco signature.asc Description: Digital signature
Re: udev and /usr
m...@linux.it (Marco d'Itri) writes: On your part, you could try to understand them instead of attributing to me straw man positions. That's a good advice. Thanks. Please help me understand: What is the usb-db and/or pci-db use case? I'm afraid my creative imagination is far too limited to come up with something without help. All the ideas I have can easily be solved without involving udev at all. Maybe someone else has any suggestions? The helpers take the pci or usb vid/pid and look them up in pci.ids or usb.ids respectively, and then add the returned strings to the available udev info as ID_VENDOR_FROM_DATABASE and ID_MODEL_FROM_DATABASE. These strings can and will change over time, so they are pretty useless in rules. And the vid/pid combination is available for the rules anyway. And stable. The only possible use I can see is for printing pretty messages to the user. But I can't see why udev has to be involved in that. Any utility wanting to do that can just look up the strings in pci.ids or usb.ids themselves. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Fri, Sep 04, 2009 at 06:58:18PM +0200, Marco d'Itri wrote: On Sep 04, Bastian Blank wa...@debian.org wrote: Why do you not extend the current setup to do another step? Currently we Even if this were possible at all, it would require (for a start): - working out all the possible side effects of synthesizing all/most (which ones?) events a second time This is already the case. - having to forward port these changes forever, with the possibility of a new architectural change making the exercise useless at any time Which change? This is an additional init script or so. You could just add another (change) trigger run after all filesystems are available. (Okay, this extra names must not be used in the fstab at all then.) No reason to bother then, persistent names are indispensable for many non-trivial systems. Hu? So you did not even read what I said. Bastian -- Madness has no purpose. Or reason. But it may have a goal. -- Spock, The Alternative Factor, stardate 3088.7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Fri, Sep 04, 2009 at 09:12:03PM +0200, Marco d'Itri wrote:
But I guess Red Hat and Suse decide. Debian does what they do, nobody
They are currently providing most of the manpower for developing udev
and the related infrastructure so this is pretty much the practical
effect, yes.
So what, you think this means we don't have any right to object when they
design things wrong?
We wrote the code, therefore it's correct if we say it is
On Fri, Sep 04, 2009 at 11:41:41AM +0200, Marco d'Itri wrote:
Yes. Any device specific matching should use vid:pid. How about just
disabling the /lib/udev/{pci,usb}-db helpers alltogether to avoid ever
getting any users of this info in Debian? It will always be too
unreliable to be useful anyway, regardless of /usr availability.
So you believe that the upstream maintainers are incompetent and
released something which is unreliable by design?
Violating the FHS is incompetent by definition and any resulting design is
unreliable.
But I have faith in udev upstream's capacity to rise above this
demonstration of incompetence.
cares about Gentoo, and Ubuntu does what Debian does. No, wait, they
don't: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/372241
This may become an interesting development, but it is not consistent
with the behaviour so far of the Canonical employees involved in the
development of udev.
That bug was reopened as a result of a conversation I had with Martin and
Scott in response to this precise thread. I was hoping Scott would be able
to shed some light on the motivation for this goofy design, but he was just
as much in the dark regarding the reason this was added and wasn't aware of
the FHS problem that had been introduced.
Do you have a reference to a thread where someone upstream has acknowledged
the existence of this FHS bug and proceeded to implement this anyway?
Either you follow the FHS or you don't. You seem to argue that most
distributions don't and that Debian therefore shouldn't either. That's
sad. Please fix the FHS first if you think it should be fixed. Or
leave it alone and fix udev instead.
Actually I am carefully avoiding to argue for either side, and trying
to provide useful facts instead.
On your part, you could try to understand them instead of attributing to
me straw man positions.
I don't see you presenting facts, I see you defending upstream violations of
the FHS. The FHS doesn't stop saying what it says just because Red Hat and
SuSE happen to decide to piss on it. It is *not* documentation of what
distros do, it is an independent standard.
You most certainly are arguing for a side, and it's not for the side that
you have an obligation to as a Debian developer.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Re: udev and /usr
]] Florian Lohoff | I have ~600 Machines in the field - all with /usr on a seperate fs - If Debian | is going to make seperate /usr a no-go its about 30 Euros worth | of field Engineer time - swapping disks. I'm fairly sure I can sell you a small shell script that you can install in the initramfs on those boxes which will do the mount before init is started, for say, 10k€? I'll even make it as a Debian package. -- Tollef Fog Heen, not really serious. UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Thu, Sep 03, 2009 at 12:53:10PM +0200, Tollef Fog Heen wrote: ]] Florian Lohoff | I have ~600 Machines in the field - all with /usr on a seperate fs - If Debian | is going to make seperate /usr a no-go its about 30 Euros worth | of field Engineer time - swapping disks. I'm fairly sure I can sell you a small shell script that you can install in the initramfs on those boxes which will do the mount before init is started, for say, 10k€? I'll even make it as a Debian package. That's not the point. /usr as a separate partition is a use case that's guaranteed by the FHS, and it's the responsibility of Debian maintainers to ensure that their packages behave correctly in this scenario. (Setting aside the question of whether the bug here is a udev bug - there /may/ be a strong architectural reason why udev needs to be the package providing this interface, in which case we must, grudgingly, move the ids files to the root filesystem; either way, the result is that we have a serious bug in one of these packages now.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: udev and /usr
Josselin Mouette wrote: Le mercredi 02 septembre 2009 à 22:30 +0200, Florian Lohoff a écrit : /usr was on seperate filesystems for decades and some 3733t broken by design Desktop utility turns around old Unix paradigms? I dont get it ... Since when is udev a desktop utility? hmm. udev doesn't requires directly /usr, instead /usr is *maybe* required by HAL (called by udev). Thus the desktop rant is still valid. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Wed, 2 Sep 2009 22:30:37 +0200, Florian Lohoff f...@rfc822.org wrote: I have ~600 Machines in the field - all with /usr on a seperate fs - If Debian is going to make seperate /usr a no-go its about 30 Euros worth of field Engineer time - swapping disks. /usr was on seperate filesystems for decades and some 3733t broken by design Desktop utility turns around old Unix paradigms? I dont get it ... Agreed. Pretty please let Debian stay a Unixoid OS, which it isn't any more if separate /usr is not supported any more. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Thu, 03 Sep 2009 13:23:11 +0200, Marc Haber mh+debian-de...@zugschlus.de wrote: On Wed, 2 Sep 2009 22:30:37 +0200, Florian Lohoff f...@rfc822.org wrote: I have ~600 Machines in the field - all with /usr on a seperate fs - If Debian is going to make seperate /usr a no-go its about 30 Euros worth of field Engineer time - swapping disks. /usr was on seperate filesystems for decades and some 3733t broken by design Desktop utility turns around old Unix paradigms? I dont get it ... Agreed. Pretty please let Debian stay a Unixoid OS, which it isn't any more if separate /usr is not supported any more. See also FHS 3.1 Purpose. /usr, /opt, and /var are designed such that they may be located on other partitions or filesystems. I do sincerely hope that we're not going to start violating this part of the FHS. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Wed, Sep 02, 2009 at 11:11:31PM +0200, Josselin Mouette wrote: Le mercredi 02 septembre 2009 à 22:30 +0200, Florian Lohoff a écrit : /usr was on seperate filesystems for decades and some 3733t broken by design Desktop utility turns around old Unix paradigms? I dont get it ... Since when is udev a desktop utility? Its not udevs idea to sort out usb/pci ids - Its whatevers consumer like hal/dbus and co decided to. udev itself is an essential tool necessary to bring up the machine so it has to go into root and not depend on any other filesystem to be there. Flo -- Florian Lohoff f...@rfc822.org Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen. - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin signature.asc Description: Digital signature
Re: udev and /usr
On Thu, Sep 03, 2009 at 12:53:10PM +0200, Tollef Fog Heen wrote: ]] Florian Lohoff | I have ~600 Machines in the field - all with /usr on a seperate fs - If Debian | is going to make seperate /usr a no-go its about 30 Euros worth | of field Engineer time - swapping disks. I'm fairly sure I can sell you a small shell script that you can install in the initramfs on those boxes which will do the mount before init is started, for say, 10k€? I'll even make it as a Debian package. Thats not the point - The point is breaking old assumptions about Debian beeing a Unixoid OS. It'll cost money somewhere - not necessarily for me but probably others. I am just making the point that this is not a lightweight decision which can be made between 12 and lunch but one which has a lot and complicated dependencies ... Flo -- Florian Lohoff f...@rfc822.org Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen. - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin signature.asc Description: Digital signature
Re: udev and /usr
Giacomo A. Catenazzi wrote: Marco d'Itri wrote: On May 31, md wrote: The issue was raised by the udev upstream maintainer along with the udev package maintainers of the major distributions, who all agreed that this configuration is not supported. FYI, udev 146 ships usb-id and pci-id programs which read /usr/share/misc/usb.ids and /usr/share/misc/pci.ids . udev itself does not care about the results of these programs but other programs which used to use HAL may do, leading to subtle breakage. Reading again your mail, I think we are discussing a inexistent problem. You say that some programs which use HAL may do use /usr/share. Hal also lives on /usr, so I don't see the problem either. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Wed, Sep 02, 2009 at 04:26:08AM +0200, Marco d'Itri wrote: On Sep 01, Steve Langasek vor...@debian.org wrote: You are drawing an artificial distinction between /usr and /var which is not consistent with the standard, nor with how I've been laying out my filesystems for years. I'm not going to refactor my disk layout on upgrade But it is consistent with what upstream (i.e., other distributions) wants to support. I have ~600 Machines in the field - all with /usr on a seperate fs - If Debian is going to make seperate /usr a no-go its about 30 Euros worth of field Engineer time - swapping disks. /usr was on seperate filesystems for decades and some 3733t broken by design Desktop utility turns around old Unix paradigms? I dont get it ... Flo -- Florian Lohoff f...@rfc822.org Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen. - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin signature.asc Description: Digital signature
Re: udev and /usr
Le mercredi 02 septembre 2009 à 22:30 +0200, Florian Lohoff a écrit : /usr was on seperate filesystems for decades and some 3733t broken by design Desktop utility turns around old Unix paradigms? I dont get it ... Since when is udev a desktop utility? -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: udev and /usr
Marco d'Itri wrote: On May 31, md wrote: The issue was raised by the udev upstream maintainer along with the udev package maintainers of the major distributions, who all agreed that this configuration is not supported. FYI, udev 146 ships usb-id and pci-id programs which read /usr/share/misc/usb.ids and /usr/share/misc/pci.ids . udev itself does not care about the results of these programs but other programs which used to use HAL may do, leading to subtle breakage. There are no obvious workarounds and I have no plan to fight against this, if you need it to work on systems with a standalone /usr then feel free to persuade the relevant maintainers to move the files. I still think /usr standalone should be supported, but I agree with you that it could be difficult to support it in actual way. Thus: Are there any technical difficulties to mount usr in the standard initramfs? I don't think there are more special /usr environments as compared of / ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
[Giacomo A. Catenazzi] I still think /usr standalone should be supported, but I agree with you that it could be difficult to support it in actual way. Thus: Are there any technical difficulties to mount usr in the standard initramfs? I don't think there are more special /usr environments as compared of / In Debian, /usr/ is allowed to be on NFS. Mounting NFS volumes from the initramfs is probably not worth the effort. I recommend moving the needed files from /usr/ to /, to get this working properly. udev need to start before /var/ and /usr/ is mounted when they are on separate partitions, and thus should only need files on /. If udev need /, /var/ and /usr/ to be on the same partition, I believe udev have a release critical bug that need to be fixed before Squeeze is released. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
Le mardi 01 septembre 2009 à 10:32 +0200, Petter Reinholdtsen a écrit : In Debian, /usr/ is allowed to be on NFS. So is /. Mounting NFS volumes from the initramfs is probably not worth the effort. How do you make root on NFS work without this? -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: udev and /usr
Josselin Mouette wrote: Le mardi 01 septembre 2009 à 10:32 +0200, Petter Reinholdtsen a écrit : In Debian, /usr/ is allowed to be on NFS. So is /. I was thinking the same, but #441291 (root over nfs) is still open. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
[Josselin Mouette] Le mardi 01 septembre 2009 à 10:32 +0200, Petter Reinholdtsen a écrit : In Debian, /usr/ is allowed to be on NFS. So is /. Perhaps, but it is not a supported solution which need to be handled by all packages. /usr/ on NFS on the other hand is a supported solution that need to be handled by all packages. I am aware that LTSP allow for such setup, but only after reorganizing the entire boot. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Sep 01, Michael Biebl bi...@debian.org wrote: Wouldn't make it sense then if udev had a recommends or at least suggests for usbutils and pciutils? Yes, the next upload (today in experimental maybe) will do this. How will usb-id and pci-id behave, if the ids files are not accessible? Print an error on stderr and exit with rc=1. The more interesting question is which packages care about this information and how they will behave when it is missing. -- ciao, Marco signature.asc Description: Digital signature
Re: udev and /usr
On Tue, Sep 01, 2009 at 01:45:23PM +0200, Marco d'Itri m...@linux.it wrote: On Sep 01, Michael Biebl bi...@debian.org wrote: Wouldn't make it sense then if udev had a recommends or at least suggests for usbutils and pciutils? Yes, the next upload (today in experimental maybe) will do this. How will usb-id and pci-id behave, if the ids files are not accessible? Print an error on stderr and exit with rc=1. The more interesting question is which packages care about this information and how they will behave when it is missing. An interesting corollary is how will upgraded systems behave ? A lot of the currently installed ones have a separate /usr. It would be a shame to tell users they have to reinstall (or go through hoops to put /usr in /) Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
hey, On 01/09/2009 Mike Hommey wrote: On Tue, Sep 01, 2009 at 01:45:23PM +0200, Marco d'Itri m...@linux.it wrote: On Sep 01, Michael Biebl bi...@debian.org wrote: Wouldn't make it sense then if udev had a recommends or at least suggests for usbutils and pciutils? Yes, the next upload (today in experimental maybe) will do this. How will usb-id and pci-id behave, if the ids files are not accessible? Print an error on stderr and exit with rc=1. The more interesting question is which packages care about this information and how they will behave when it is missing. An interesting corollary is how will upgraded systems behave ? A lot of the currently installed ones have a separate /usr. It would be a shame to tell users they have to reinstall (or go through hoops to put /usr in /) do we really consider to stop support for seperate /usr? after all fhs supports seperate /usr by design. [1] i hope that we keep fhs compability within debian. greetings, jonas [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#THEROOTFILESYSTEM signature.asc Description: Digital signature
Re: udev and /usr
Jonas Meurer wrote: do we really consider to stop support for seperate /usr? after all fhs supports seperate /usr by design. [1] i hope that we keep fhs compability within debian. I agree, but the problem is how?. Moving too much thinkgs from /usr to / is also against the design of FHS, thus i prefer requiring /usr not to be mountable. BTW we doing worse things: we are not only requiring /usr to be in the root partition, but also /usr/share. We could move the ids files in /lib (or /usr/lib): I really thing /usr/share should be nfs mountable! ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Tue, Sep 01, 2009 at 03:01:35PM +0200, Giacomo A. Catenazzi wrote: Jonas Meurer wrote: do we really consider to stop support for seperate /usr? after all fhs supports seperate /usr by design. [1] i hope that we keep fhs compability within debian. I agree, but the problem is how?. i make no claims about the on-crackiness of the following suggestion, but: what about smuggling such precious and required files into the initrd, and either copying them at boot time or having a temporary bind-mount to make them available until the real /usr can take over? sean signature.asc Description: Digital signature
Re: udev and /usr
Mike Hommey wrote: An interesting corollary is how will upgraded systems behave ? A lot of the currently installed ones have a separate /usr. It would be a shame to tell users they have to reinstall (or go through hoops to put /usr in /) Well, /usr is supposed to be shareable between hosts; forcing it to be on the same filesystem as / is very sub-optimal. -- Chris Jackson Shadowcat Systems Ltd. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Tue, Sep 01, 2009 at 11:18:47AM +0200, Giacomo A. Catenazzi wrote: Josselin Mouette wrote: Le mardi 01 septembre 2009 à 10:32 +0200, Petter Reinholdtsen a écrit : In Debian, /usr/ is allowed to be on NFS. So is /. I was thinking the same, but #441291 (root over nfs) is still open. Reading #441291, it's not about root over NFS but rather installing over NFS. Root over NFS works fine here. I had to hack around a bit because / not only comes from NFS but it is also R/O, but that's a different can of worms to open. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
Le mardi 01 septembre 2009 à 13:41 +0100, Chris Jackson a écrit : Well, /usr is supposed to be shareable between hosts; forcing it to be on the same filesystem as / is very sub-optimal. / is shareable as well, if you mount it read-only. Everything that has been said about /usr in this thread can also be said about /, so please think about it before making propositions. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: udev and /usr
Josselin Mouette wrote: / is shareable as well, if you mount it read-only. Everything that has been said about /usr in this thread can also be said about /, so please think about it before making propositions. Well, /etc needs to be on /, since otherwise you can't get to fstab to mount it, and generally things like /etc/hostname will be different, so, while I suppose it's theoretically possible, I'd take it also to be somewhat sub-optimal. -- Chris Jackson Shadowcat Systems Ltd. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
Josselin Mouette wrote: Ever heard of DHCP ? Mmm, fair enough. Anyway, it isn't true that what's said about /usr also applies to / since, once init is running (and a little before that), we definitely have a /, but may not have a /usr yet, or /usr may fail to mount. I'm not 100% sure whether the files in question are needed in such a circumstance, but that's the question that needs thinking about. -- Chris Jackson Shadowcat Systems Ltd. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Tue, Sep 01, 2009 at 01:45:23PM +0200, Marco d'Itri wrote: How will usb-id and pci-id behave, if the ids files are not accessible? Print an error on stderr and exit with rc=1. The more interesting question is which packages care about this information and how they will behave when it is missing. $ ls -l /usr/share/misc/usb.ids lrwxrwxrwx 1 root root 25 2009-08-24 12:01 /usr/share/misc/usb.ids - /var/lib/usbutils/usb.id So the title is not correct, it's not just /usr, but /var also needs to be mounted. How about re-running the rules after all the filesystems have been mounted? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Sep 01, Gabor Gombas gomb...@sztaki.hu wrote: How about re-running the rules after all the filesystems have been mounted? No. -- ciao, Marco signature.asc Description: Digital signature
Re: udev and /usr
On Tue, Sep 01, 2009 at 04:47:54PM +0200, Josselin Mouette wrote: Le mardi 01 septembre 2009 à 15:36 +0100, Chris Jackson a écrit : Well, /etc needs to be on /, since otherwise you can't get to fstab to mount it, and generally things like /etc/hostname will be different, so, while I suppose it's theoretically possible, I'd take it also to be somewhat sub-optimal. Ever heard of DHCP ? Do we only support network configuration with DHCP now? Neil -- twb I don't see why anyone would want to cyber with a 16yo. IME none of them can spell, and they probably haven't had the relevant experience to write convincing prose. It's not like their ASCII is going to be any more supple for them being sixteen. signature.asc Description: Digital signature
Re: udev and /usr
Neil McGovern wrote: Do we only support network configuration with DHCP now? That's not the point, the slightly off-topic point we got onto was that you can in fact share / between hosts if you're using DHCP. I don't think the FHS supports it, but I can see uses for it in places. -- Chris Jackson Shadowcat Systems Ltd. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Tue, Sep 01, 2009 at 05:24:19AM +0200, Marco d'Itri wrote: The issue was raised by the udev upstream maintainer along with the udev package maintainers of the major distributions, who all agreed that this configuration is not supported. FYI, udev 146 ships usb-id and pci-id programs which read (ed: usb-db, pci-db) /usr/share/misc/usb.ids and /usr/share/misc/pci.ids . udev itself does not care about the results of these programs but other programs which used to use HAL may do, leading to subtle breakage. Anything that used to use hal was dependent on an executable located in /usr/sbin, so presumably all such packages already wait until /usr is mounted before expecting results. Why do programs need udev to read this information in at driver load time? Why can't packages that need this information query it when they need it (which is well after /usr is mounted), instead of expecting udev to provide it? What are the programs that are behaving this way, and why should we not consider *those* to be buggy for expecting udev to feed it text strings out of a database? There are no obvious workarounds and I have no plan to fight against this, if you need it to work on systems with a standalone /usr then feel free to persuade the relevant maintainers to move the files. I also opened #544503 because supporting a standalone /var looks like a worthwhile effort, while supporting updating usb.ids with a script instead of apt looks like a complete idiocy. You are drawing an artificial distinction between /usr and /var which is not consistent with the standard, nor with how I've been laying out my filesystems for years. I'm not going to refactor my disk layout on upgrade to accomodate your (or udev upstream's, or that of the upstream of any of these other programs) blatant disregard for the FHS. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Sep 01, Steve Langasek vor...@debian.org wrote: Why do programs need udev to read this information in at driver load time? Why can't packages that need this information query it when they need it (which is well after /usr is mounted), instead of expecting udev to provide it? I did not design this aspect of udev, I am just packaging it. What are the programs that are behaving this way, and why should we not consider *those* to be buggy for expecting udev to feed it text strings out of a database? I don't know, maybe you should discuss this on the linux-hotplug mailing list. You are drawing an artificial distinction between /usr and /var which is not consistent with the standard, nor with how I've been laying out my filesystems for years. I'm not going to refactor my disk layout on upgrade But it is consistent with what upstream (i.e., other distributions) wants to support. -- ciao, Marco signature.asc Description: Digital signature
Re: udev and /usr
Marco d'Itri wrote: On May 31, md wrote: The issue was raised by the udev upstream maintainer along with the udev package maintainers of the major distributions, who all agreed that this configuration is not supported. FYI, udev 146 ships usb-id and pci-id programs which read /usr/share/misc/usb.ids and /usr/share/misc/pci.ids . udev itself does not care about the results of these programs but other programs which used to use HAL may do, leading to subtle breakage. Reading again your mail, I think we are discussing a inexistent problem. You say that some programs which use HAL may do use /usr/share. But these programs could use also other partitions (e.g. starting a daemon, thus needing /var) or other services (NIS+,..). Thus I think the problem should be solved on the HAL programs, which must wait, or support early boot. Eventually we must only document that /usr (and ev. also /usr/share) could NOT be on different partition if user install few programs. (which one?) OTOH usb.ids and pci.ids are not complete, thus a program should not expect a usefull result. usb.ids and pci.ids are included in the kernel, thus on early boot procedure we could recycle that informations to build at every hotplug event some tiny ids files. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
Marco d'Itri wrote: On May 31, md wrote: The issue was raised by the udev upstream maintainer along with the udev package maintainers of the major distributions, who all agreed that this configuration is not supported. FYI, udev 146 ships usb-id and pci-id programs which read /usr/share/misc/usb.ids and /usr/share/misc/pci.ids . Wouldn't make it sense then if udev had a recommends or at least suggests for usbutils and pciutils? udev itself does not care about the results of these programs but other programs which used to use HAL may do, leading to subtle breakage. How will usb-id and pci-id behave, if the ids files are not accessible? There are no obvious workarounds and I have no plan to fight against this, if you need it to work on systems with a standalone /usr then feel free to persuade the relevant maintainers to move the files. I also opened #544503 because supporting a standalone /var looks like a worthwhile effort, while supporting updating usb.ids with a script instead of apt looks like a complete idiocy. I agree with you. Given that I had more than once bug reports against hal due to broken pci.ids or usb.ids files, I'd prefer if update-usbids and update-pciids would go away. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
