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
> WRITTEN TO."
>
> 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: