pciutils-2.2.4 uses a cron job to update /usr/share/misc/pci.ids.gz. This does not work for a read-only /usr partition. According to the FHS 2.3 (chpater 4): | /usr is shareable, read-only data. That means that /usr should | be shareable between various FHS-compliant hosts and must not be | written to. Any information that is host-specific or varies with | time is stored elsewhere. pci.ids.gz should be moved to /var/lib/misc (probably with a symlink to its old location). Another question is, if it is a good idea to unconditionally enable that periodic update.
*** Bug 161298 has been marked as a duplicate of this bug. ***
So remove the cronjob if you can't live with it or ask upstream to make pciutils search for the IDs in /var/lib. (And noone said that Gentoo is FHS compliant in cases when it doesn't make sense).
This is _not_ an upstream issue. The cron file is a Gentoo addition. Reopening. (And yes, sometimes it does make sense to have /usr mounted read-only. If you have several client machines with NFS-mounted /usr you definitely don't want to have this automatic update feature. At least not per default.)
(In reply to comment #3) > This is _not_ an upstream issue. The cron file is a Gentoo addition. > Reopening. Huh? The pci.ids file location is a Gentoo issue? Has nothing to do w/ the cronjob in case you missed that.
(In reply to comment #4) > Huh? The pci.ids file location is a Gentoo issue? > Has nothing to do w/ the cronjob in case you missed that. The programs from the vanilla package will not write to /usr, only the Gentoo cronjob does that.
*** This bug has been marked as a duplicate of bug 156183 ***
(In reply to comment #5) > (In reply to comment #4) > The programs from the vanilla package will not write to /usr, only the Gentoo > cronjob does that. WTH are you talking about? # equery f pciutils | grep pci.ids.gz /usr/share/misc/pci.ids.gz
(In reply to comment #7) > WTH are you talking about? > > # equery f pciutils | grep pci.ids.gz > /usr/share/misc/pci.ids.gz The file belongs to the package, so what? The point is that the vanilla/upstream package will install the file once, and then will happily function even with a readonly /usr partition. The cron job will only work if /usr is mounted r/w. Is it so difficult to understand?
we're tracking the user-opt-in aspect of cronjob in the duplicate bug
(In reply to comment #8) > Is it so difficult to understand? Yeah, it's indeed difficult to understand why are you not trying to fix the *real* issue upstream and instead are bugging us w/ a cronjob.
will you just shut up the issue is Gentoo's cronjob
vapier: Thanks for the moral backing. ;) Concerning /usr vs. /var, I'd like to point you to the following short thread in freestandards-fhs-discuss: <http://sourceforge.net/mailarchive/message.php?msg_id=15170824> Their conclusion is that having pci.ids in /usr/share is o.k. if update-pciids is invoked manually. It looks like Debian has moved the file from /usr to /var and back to /usr again, see <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=278479> They don't have a cronjob, though.
we're not moving the file from its current location ... we'll just be making the cronjob a USE flag
What about a symlink? Wouldn't that satisfy both of you (and me)? :-)
> What about a symlink? Wouldn't that satisfy both of you (and me)? :-) In most configurations where you have a readonly /usr (e.g. NFS mounted) you problably wouldn't want to have that auto-update feature at all. I believe the USE flag is the better solution.
update-pciids now checks to see if the file is read-only and if so, skips updating the file
