Bug#40706: usr/share/doc vs. /usr/doc
On Sun, 04 Jul 1999, Steve Greenland wrote:
> > Because Debian is the distribution, where the user can upgrade or
> > keep every single package without any drawbacks.
> ^^^^^^^^^^^^^^^^^^^^^
> Who says that?
I say this. IMHO this is one of the main advantages of Debian over
other distributions.
> Agreed, users should not be forced to upgrade unnecessarily, nor
> accross-the-board, and we should make that as painlesl *as
> reasonably feasible*.
That's what I mean.
> When we add/change a feature, we should *attempt* to minimize the
> pain,
That's the subject of this thread.
> but it is not unreasonable to expect people to upgrade the affected
> packages to take advantage of that feature.
But for the /usr/doc vs. /usr/share/doc topic this means, that the
user has to upgrade _all_ packages (Presumed that _all_ developers
rebuild _all_ packages according to FHS soon, which isn't very
realistic).
So I think, that it is preferable to add some backward compatibility
into the new FHS compliant packages, either by creating a symlink
/usr/doc/<package> to /usr/share/doc/<package>, as I proposed or by
some more intelligent techniques, that may remove these symlinks or
something like this. I started this thread to find the ultimate
solution for this, other proposals are very welcome.
IMHO it is less work to create these symlinks (or something like
this), which could be done automatically by debhelper, than explaining
all Debian users why they have to hunt the documentation in two
different directories. As a user I think, that a distribution should
provide a way to access all package documentations in one directory.
If a distribution isn't able to do so, this is a bug of the
distribution.
> > So we cannot expect the user to upgrade every package from one
> > stable to the next stable.
> Yes, but then the user shouldn't expect to have all the "benefits"
> of the next stable release, such as full FHS compliance.
How long do you want to wait for potato to be released? It takes time
to change >3000 packages and every package has to be changed for this
(maybe debhelper will do parts of this job, but every package has to
be recompiled on all architectures). I fear that it is completely
unrealistic, that potato be fully FHS complaint. So potato will be a
mix of FSSTND and FHS and we should now look for a way to make this
mix as usable for human users as possible. Simply pushing the user
into the cold water and let him find out which package places its
documentation in /usr/doc and which uses /usr/share/doc isn't an
acceptable way.
> > But with some packages in /usr/doc and others in /usr/share/doc we
> > need some way for the user to quickly find the correct directory
> > for a special package.
> ls -l /usr/doc/<package>
> ls -l /usr/share/doc/<package>
That's not really user friendly. That's a job which can be done much
better by the distribution or by some tool.
Don't forget that we don't want to produce a distribution only for
freaks but also for "normal" humans.
> > That's the point. So tell me how the user can find out where the
> > documentation for package xy is located without checking two
> > directories (which is annoying)?
> Life's annoying.
And we have computers to annoy us as less as possible.
> Or perhaps
> if [ -d /usr/doc/$1 ] ; then
> cd /usr/doc/$1
> elif [ -d /usr/share/doc/$1 ] ; then
> cd /usr/share/doc/$1
> else
> echo "No documentation directory found for package $1"
> fi
> accompanied by 'alias finddoc=". ~/bin/finddoc".
That's some kind of work around, but it doesn't help me with this:
$ less /usr/doc/<package>/copyright
because it changes the directory, which I don't like. Yes, I know I
could create another alias for viewing a package copyright and a
package changelog, but this isn't as comfortable as it was before when
using the TAB-completion mechanisms of tcsh or bash.
As long as there are alternatives which annoy the user less, I think
we should provide these alternatives and a symlink /usr/doc/<package>
to /usr/share/doc/<package> is such an alternative.
Ciao
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: