Re: Essential stuff in /usr/doc (Was Re: Installing things into a...)
"Peter" == Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> 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
Reply to: