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

Re: strange behavior of dh_dhelp

Marco Budde <mbudde@sms.antar.com> wrote:

> Ok, then Debian 2.2 will be broken.

No. There are not many packages which quickly switched to
/usr/share/doc without the symlinks.  The maintainers of these
packages quickly changed, so they are alive and the should be able to
add the symlink to their next versions of the packages as quickly as
they uploaded before.  So why should 2.2 be broken?  Potato _is_
broken at the moment, but this can be fixed.

> And the next releases will have the same problems, because we still
> allow policy 2.4 packages without any symlinks.

The next (potato+1) requires all documentation in /usr/share/doc _and_ 
Symlinks in /usr/doc.

> So it won#t be possible to install Debian 2.2 and 2.3 packages on
> one system with a working documentation.

So there is no problem with 2.2+2.3.  Then 2.4 will remove the
symlinks but now all packages from 2.3 placed their docs in
/usr/share/doc, so you can use packages from 2.3+2.4 together with all 
docs in /usr/share/docs.

> Wrong. Symlinks don#t work with http.

What does the HTTP protocol have to do with the Unix file system?
It depends on the HTTP server, whether it follows symlinks or not.
Apache handles this without problems for ages and FollowSymlinks is
activated in the default configuration for /usr/doc.

I think that other HTTP servers will do the same, and if one doesn't
do so, it's more likely that they support to follow symlinks instead
of _not_ to follow symlinks.  BTW: I think that it is a bug, if an
HTTP server isn't configurable in this case.

And don't forget that we already have many symlinks in /usr/doc for
ages, which are explicitly allowed by policy:

     /usr/share/doc/<package-name> may be a symbolic link to a directory in
     /usr/share/doc only if two packages both come from the same source and
     the first package has a "Depends" relationship on the second. These
     rules are important because copyrights must be extractable by
     mechanical means.

> If you ask me:

>   (1) All packages of Debian 2.2 must use /usr/share/doc.

Then the release date of 2.2 will be at the end of 2000 or later.
That's simply unrealistic.  If you personally want to upload 2000 NMUs 
(for each architecture!), this may be able sooner, but....

>       Otherwise we will have the same problems in Debian 2.3, when
>       the user reads the documentation via /usr/share/doc.

No.  Read the time table above or in one of my last mails.

>   (2) All packages provides /usr/doc links.

That's right for 2.2 and 2.3.

>   (3) http://localhost/doc/ points to /usr/share/doc, the user
>       use /usr/share/doc instead of /usr/doc.

That's wrong.  http://localhost/doc/ points to /usr/doc in 2.2 and
2.3.  This will change in 2.4.

> This is a clean solution

It is clean if all Debian maintainers update all their packages in all 
architectures and if every user upgrades the complete system from 2.1
to 2.2 and not only parts.  If you cannot be sure that these
requirements are resolved, it is not clean.

> and not such a hack like the descripted decision.

Yes, the decision is a hack.  But it works and offers a smooth
transition.  We have to release potato soon (slink is very old and our 
users want a new release, otherwise the may use a different
distribution) and potato should be as consistent as possible.  The
hack gives us a consistent potato (all doc available via /usr/doc),
your proposal does not.

Anyway, the decision was made, like it or hate it but stop discussing
it again and again. This doesn't help and won't change anything.



 * 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: