Re: Can /usr/share/doc/<pkg> be deleted on upgrade ?
Hi, Ben:
On Saturday 28 November 2009 08:59:13 Ben Finney wrote:
> "Jesús M. Navarro" <jesus.navarro@undominio.net> writes:
> > Not personal but sysadmin related. When I want to find information
> > about a given package I go to /usr/share/doc/<pkg> so I find
> > reasonable that the local sysadmin would add notes about the package
> > right there if needed.
>
> No, I don't think that's reasonable. The ‘/usr’ hierarchy (with the
> important exception of ‘/usr/local’) should be considered entirely the
> province of the package management system; any files there can appear or
> disappear as dictated by the packages.
>
> The sysadmin's site-local files should be going under ‘/usr/local’,
> which *is* out of bounds for the package manager.
Strongly questionable: notes about package emacs, installed via package
manager might go under /usr/share/doc/emacs, why not.
> > Less surprise path.
>
> That's the benefit of following standards like the FHS: there are places
> like ‘/usr’ that can be managed entirely by the package manager. Anyone
> surprised by that isn't following established convention.
Quite a strong asumption given that FSH doesn't say a word *at all* about
package managers.
And what it says about /usr is:
"/usr is the second major section of the filesystem. /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."
regarding /usr/share it says:
"The /usr/share hierarchy is for all read-only architecture independent data
files."
So:
a) Nothing is said about /usr being "package manager's-only realm".
b) Nothing prevents the administrator to peruse /usr/share/doc/ from including
architecture-independent data regarding whatever is installed, specially if
its about something root-based (in contrast to local-based).
c) deleting whole directories disregarding their contents is not what Debian
usually does.
Reply to: