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. manoj -- O'Brian's Law: Everything is always done for the wrong reasons. Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org