"Peter" == Peter S Galbraith <[EMAIL PROTECTED]> writes: > > Peter> Manoj Srivastava wrote: > > >> Umm. I should be able to nuke /usr/doc on a machine and still > >> have it work > > Peter> Why would you expect that? It's not policy yet. Some packages > Peter> have _all_ their useful info in /usr/doc (debian-policy, > Peter> developers-reference, mh-book, etc) > > Yes, it is not policy (yet). I did not say it is an erorr -- > or that it violates policy. I just intended to comment it is not an > unreasonable thing for users to do. > > Oh, I would expect that if I remove /usr/doc, I shall have no > access to the documentation thus removed (well, duh). That includes > the documentation only packages. I was not aware we were talking > about doc only packages here, though.
Maybe not, but they would be affected by such a measure. It would be nice to have non-essentiel readme files, changelogs and copyright files in a tree that you could delete and _really_ not affect anything. Perhaps putting real docs in /usr/share would be a good way to do that. But, as you also say, that would get by things like the http /usr/doc -> /doc link. > Peter> If we (collectively) decided to do that as policy, then the above > Peter> packages would surely be changed to move essential files out of > Peter> /usr/doc. So why suggest different rules on wdg-html-validator? > > If we so collectively decide, then the move shall be > mandatory. All I am saying is that while we have a choice, there are > reasons not to put things that the package needs while working in > /usr/doc. I am not forcing anyone, I am merely offering advice. > > This is the -mentor list, is it not? Not the -policy list? I > am offering what I think is a better solution, not that the solution > provided violated policy. > > You may choose to ignore advice. Don't get upset. I was simply pointing out a flaw (that deleting /usr/doc would break documentation packages). > I think that if we choose not to put things in /usr/doc > voluntarily, then it a) shall be easier for for people to nuke > /usr/doc on their machines, and b) make it less of an effort to move > things off. It also makes them invisible to http:/doc (but as you say, `well, duh'). ;-) > Peter> (I have a perhaps similar problem with mh-book: I wrote a cgi-bin > Peter> search engine that returns URLs like file:/usr/doc/mh-book/... > Peter> and so it won't really work for remote hosts accessing mh-book > Peter> through http://SERVER_NAME/doc/mh-book; the solution is probably > Peter> to return http://SERVER_NAME/doc/mh-book URLs instead of > Peter> file:/usr/doc/mh-book because that also works locally but then I > Peter> have to parse config files to get the SERVER_NAME like dwww does. > Peter> I assume I can't expect $ENV{SERVER_NAME} to work for all > Peter> cgi-bin capable web servers as it does for Apache) > > But not all cgi-bin capable browsers ;-) I think I'll simply check $ENV{SERVER_NAME} and use it if defined. That will cover a good proportion of cases anyway. Peter
