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

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: