Bugzilla Bug 161296

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