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

Re: software updates file in /usr -- policy bug?

On Mon, 25 Oct 2004, martin f krafft wrote:

> Hi all,
> apt-spy and pciutils (and possibly others) contain methods to update
> a database integral to their operation.
>   - `apt-spy update` downloads the list of available Debian mirrors
>     to /usr/share/apt-spy (see #277816).
>   - `update-pciids` downloads a new /usr/share/misc/pci.ids
> I think these are both in violation with the FHS, which states
> (Chapter 4, emphasis mine, using caps instead of asterisks for
> readability):
>   "/usr is shareable, READ-ONLY DATA. That means that /usr should be
>   shareable between various FHS-compliant hosts and MUST NOT BE
> The apt-apy maintainer thinks this is okay because (from the bug
> report):
>   apt-spy does not "dynamically update".  It updates *if and ONLY
>   if* you ask it to.  I do not see this as a violation of the spirit
>   of the FHS.  I'm more than happy to have discussion about this.
> If this holds, then why does `apt-get update` modify files in
> /var/lib/apt/lists, and why is /var/lib/dpkg/status not really
> /usr/lib/dpkg/status?
> Well, two wrongs don't make a right, nor does APT/dpkg's choice for
> /var make using /usr for changeable resource data wrong for
> everyone, but I still think that apt-spy's mirror list and the PCI
> IDs should be kept in /var, since they are variable data.

Having a program asking the user "do you want to violate the FHS?"
does not make it not to be a violation. I would much prefer not to
have to answer such questions.

Some people might want to have /usr mounted read-only except when
using dpkg/apt to upgrade the system. The FHS says this should work,
so any program which fails because it tries to write to /usr could be
considered as a bug.

Even if the file is updated only by the postinst, it is useful to know
that you can recover a broken system from scratch by having:

* A backup copy of /etc, /var, /home, /usr/local, etc. (but not /usr).
* The list of installed packages.

I think this is a good property of the system that we should try to keep.

Would the user benefit from having the freedom to change apt-spy or pci.ids?
If yes, then those files would be much better placed in /etc. Just because
it is a "database" does not mean it may not be modified by the user.
Think about /etc/services for example.

Reply to: