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

Re: Can /usr/share/doc/<pkg> be deleted on upgrade ?

Hi, Manoj:

On Sunday 29 November 2009 04:53:05 Manoj Srivastava wrote:
> On Sat, Nov 28 2009, Jesús M. Navarro wrote:
> > 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.
>         Why not? Because it is not safe, that's why. There is no
>  guarantee made by Debian that your files shall not be stomped on, or
>  that user data will be preserved.

My general stanza is not that would be the best/more sensible place to put 
files on (I already said I never did it) nor that there isn't a note on some 
(quite hidden) place saying that's against procedure.  It's a bit on a higher 
level: there's some obvious common behaviour deleting whole (non-empty) 
directories is not the usual way so unless there are strong reasons (it makes 
a bit easier going that way because so does the upstream maintainer I don't 
think qualifies) I'd favour *not* to do that.  Do you really find intuitive 
going to /usr/local/share/doc/emacs to look for extra docs about the 
package-managed installed emacs -specially when this package already has all 
its documentation under /usr/share/doc/emacs?  Well, I don't.

>         But Debian also does not tell you that your file will be there
>  with the next upload. If you name your file foo.txt, there is nothing
>  that guarantees that the next version will not have an empty file
>  called foo.txt in that dir in /usr. Nothing checks to see i there is a
>  user file there. And, by the same token, when the next+1 version
>  removes foo.txt, dpkg will happily remove it.

True.  But again by comparation to other similar behaviours I'd find quite odd 
that the system would remove/replace /usr/share/<pkg>/local-notes.txt or 
even /usr/share/doc/<pkg>/mycompany-notes.txt (I think I remember the 
prefix "local-" to be safe at least under /etc).  I know that only files 
under /etc (well, files marked as "config") are safe to be tweaked by the 
local administrator on Debian but even that shows more of a 
limitation/compromise from the used tools than a real common-sense/best world 
policy (it'd be better to track *all* files, i.e. by means of md5sums, were 
it not too expensive/burdensome).

>         So, the user is well advised not to trust any  user  data under
>  /usr/share, should be using /usr/local anyway. Given that, while a
>  trifle odd, I see nothing wrong in removing and recreating
>  /usr/share/doc/<pkg> with every install.

Then why /etc/<pkg>, /var/lib/<pkg> or /var/log/<pkg> won't get the same fate?  
What's *so* different about /usr/share/<pkg> as to expect it to be managed so 
differently? (again, I am not saying that there isn't a reason nor that it is 
even written down somewhere but I'm questioning the overall sensibleness of 
such a policy; after all the main reason d'etre for a distribution effort is 
giving a focused common  behaviour and integration of an otherwise disparaged 
bunch of packages; the less details/exemptions for the policy, the better).

Reply to: