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

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

On Sun, Nov 29 2009, Jesús M. Navarro wrote:

> Hi, Manoj:
> On Sunday 29 November 2009 04:53:05 Manoj Srivastava wrote:
>> On Sat, Nov 28 2009, Jesús M. Navarro wrote:

>> > 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.

        Feel free to add a note someplace, then.

> 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

        Well, yes.  The vendor documentation is in /usr/share/doc/emacs,
 I would not expect site specific docs there. I would indeed look into
 /usr/local/share/emacs first.

> -specially when this package already
> has all its documentation under /usr/share/doc/emacs?  Well, I don't.

        Well, then don't put the notes there.  Select whatever place is
 logical to you and your fellow users.

>>         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).

        Why is it odd if such a file were added upstream?

>>         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).

        What makes you think that the other directories (apart from
 /etc/*) are any safer? You are only guaranteed /usr/local belongs to
 you, and that your changes in files in /etc shall be preserved.

        That's all you got.

O'Brian's Law: Everything is always done for the wrong reasons.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: