[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: when move /usr/doc -> /usr/share/doc ?



Jonathan Walther <krooger@debian.org> wrote:

> So when are we going to start moving /usr/doc to /usr/share/doc so
> we can be fully FHS compliant?

The (not yet released) debian-policy 2.5.1.90 (which should become
3.0.0 soon) already uses /usr/share/doc.

So the move may be quite near.

> The more I think about it, the more obvious it is that /usr/share is
> the sanest place to put the doc directory.

It is the sanest place and it is architecture independent like
/usr/share/man and /usr/share/info, so doc should be placed in
/usr/share.

The problem with this change is, that there is no generic way to find
the documentation for the packages, if it is distributed between
/usr/doc and /usr/share/doc. This is no problem with man and info,
because the man- and info- browsers are (or: should be) aware of this
and handle both locations. But how does this work for doc? At the
moment I always find the documentation under /usr/doc/<package>. Do I
have to search for this in /usr/doc and /usr/share/doc in the near
future? IMHO this is very annoying.

And what about the local web server which presents /usr/doc/ as
http://localhost/doc/ at the moment? How is this intended to work, if
the documentation is distributed between /usr/doc and /usr/share/doc
in the phase of transition (when one half of the packages use one
directory and the other half uses the other)?

Maybe by installing the documentation under /usr/share/doc/<package>
and creating a symlink /usr/doc/<package> pointing to this location.
Then all documentation will be available as /usr/doc/<package> in the
transition phase and in the far future (when every package is re-build 
using /usr/share/doc), we can remove /usr/doc and switch over to
/usr/share/doc.

I know that this "solution" isn't clean, but it's the only way I see
at the moment, if we don't want to re-build every ~3000 packages at
once (which means only a good profit for our telco providers, but
doesn't make much sense apart from that).

Tschoeeee

        Roland

-- 
 * roland@spinnaker.de * http://www.spinnaker.de/ *
 PGP: 1024/DD08DD6D   2D E7 CC DE D5 8D 78 BE  3C A0 A4 F1 4B 09 CE AF


Reply to: