Re: Can /usr/share/doc/<pkg> be deleted on upgrade ?
Hi again, Manoj:
On Sunday 29 November 2009 21:00:14 Manoj Srivastava wrote:
[...]
> Well, then don't put the notes there. Select whatever place is
> logical to you and your fellow users.
Like... /usr/share/doc/emacs? (again on square one).
>
> >> 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?
That's not an argument (not by itself, at least). There are a lot of things
upstream can do that's undone at packaging in order to comply with Debian
policy. If it *were* (a big if, of course) the policy that local-* files are
sacred then something should be done. On the other hand that finding a
[mycompany]-whatever would be odd is just a matter of statistics.
And regarding behaviour, because of Debian Policy's D.2.2 Size and MD5sum.
Since md5sums are already part of the binary package definition it might be
expected a good thing the same kind of logic like that of config files to be
applied. Is it current checksum different from both the version installed
and the new one? Then shout out loud. Again, why having two different
behaviours when you can have one?
> 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.
The point with having policies plagued with exceptions and special cases is
that even the policy makers tend to forget them. I.e. If you have a look
around either the Debian Policy Manual or Debian Developer's Reference you'll
find that directories are almost never mentioned. With a few exceptions
where talking explicitly about directories (like how/when packages may create
them under /usr/local/<whatever> yes, it might be the case) it's always about
files this or files that and the times directory deletion is exemplified is
always using rmdir (which, of course will fail -as expected, on non-empty
ones)
> That's all you got.
I know that's what I got. The question is: is that the best I could get?
> --
> O'Brian's Law: Everything is always done for the wrong reasons.
Uh... quite on spot for this thread.
Reply to: