Re: Essential stuff in /usr/doc (Was Re: Installing things into a...)
Hi,
>>"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.
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.
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.
>> The problem is similar to that of navigation button images in
>> html files generated by latex2html. The solution there was to create
>> the /var/www/usr/lib/latex2html/icons/ dir, and symlink the iocons in
>> from /usr/lib/latex2html/icons/.
Peter> Isn't that simply so the same links work with either prefix file: or
Peter> http://host/ ? (I speak without knowledge of that package).
That too. I understand that we are talking about a CGI script?
Well, there were browsers that could run CGI scripts without needing
a server (lynx?), and the /usr/doc ==> /doc alias is not visible. My
latex2html hack enables one to use lynx on ones local machine for a
quick look.
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 ;-)
manoj
--
You should never bet against anything in science at odds of more than
about 10^12 to 1. Ernest Rutherford
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: