Debian Bug report logs - #40706
[REJECTED 21/7/99] /usr/share/doc vs. /usr/doc transition

version graph

Package: debian-policy; Maintainer for debian-policy is Debian Policy List <debian-policy@lists.debian.org>; Source for debian-policy is src:debian-policy.

Reported by: Roland Rosenfeld <roland@spinnaker.de>

Date: Sun, 4 Jul 1999 00:33:07 UTC

Severity: fixed

Found in version 3.0.0.0

Done: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roland Rosenfeld <roland@spinnaker.de>:
New bug report received and forwarded. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Roland Rosenfeld <roland@spinnaker.de>
To: submit@bugs.debian.org
Subject: /usr/share/doc vs. /usr/doc
Date: Sun, 4 Jul 1999 02:27:01 +0200
Package: debian-policy
Version: 3.0.0.0
Severity: important

debian-policy 3.0.0.0 is now out and mentions to use
/usr/share/doc/<package> instead of /usr/doc/<package>.

This is principally the right way (according to FHS), but we cannot
recompile all packages now but we need a smooth way from one directory 
to the other.

We need an official way (noted in the policy or at least in
upgrading-checklist) to migrate from /usr/doc to /usr/share/doc,
otherwise the package maintainers will distribute the document files
between the two directories and users have to search both directories
to find the correct location of the files and web servers are no
longer able to detect the documentation as
http://localhost/doc/<package>.

So please let us handle this question with high priority, before there 
are packages uploaded, with documentation which cannot be found as
/usr/doc/<package>.


I don't have an optimal solution for this question, but the following
seems to do the job:

- New packages should use /usr/share/doc/<package> and create a
  symlink /usr/doc/<package> pointing to /usr/share/doc/<package>.
- The symlink allows us to access every documentation as
  /usr/doc/<package> in the transitional period.
- After the transitional period (when every package places its
  documentation under /usr/share/doc/<package>), we can find every
  package documentation as /usr/share/doc/<package>.
- At this time we can begin removing the symlinks when new packages
  are uploaded.


I would like to hear of better methods for a smooth transition, but I
did not see any better solution yet (other ideas intend to tell the
web sever to search both directories, but this doesn't help the user
who is searching the correct directory).

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


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to "Darren O. Benham" <gecko@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #10 received at 40706@bugs.debian.org (full text, mbox):

From: "Darren O. Benham" <gecko@debian.org>
To: Roland Rosenfeld <roland@spinnaker.de>, 40706@bugs.debian.org
Subject: Re: Bug#40706: /usr/share/doc vs. /usr/doc
Date: Sat, 3 Jul 1999 18:44:57 -0700
[Message part 1 (text/plain, inline)]
On Sun, Jul 04, 1999 at 02:27:01AM +0200, Roland Rosenfeld wrote:
> This is principally the right way (according to FHS), but we cannot
> recompile all packages now but we need a smooth way from one directory 
> to the other.
Why do we need a smooth way?  Some packages (including many of mine at the
moment) are outta Policy compliance... If it's not a release critical bug,
it doesn't have to be fixed before Potato goes out.

The FHS has a preferd way to make the transition... it's a symlink.  There
might be reasons you don't want it on *your* computer, but what is wrong
with that track as a default for Debian?
> 
> 
> We need an official way (noted in the policy or at least in
> upgrading-checklist) to migrate from /usr/doc to /usr/share/doc,
> otherwise the package maintainers will distribute the document files
> between the two directories and users have to search both directories
> to find the correct location of the files and web servers are no
> longer able to detect the documentation as
> http://localhost/doc/<package>.
> 
> So please let us handle this question with high priority, before there 
> are packages uploaded, with documentation which cannot be found as
> /usr/doc/<package>.
> 
> 
> I don't have an optimal solution for this question, but the following
> seems to do the job:
> 
> - New packages should use /usr/share/doc/<package> and create a
>   symlink /usr/doc/<package> pointing to /usr/share/doc/<package>.
> - The symlink allows us to access every documentation as
>   /usr/doc/<package> in the transitional period.
> - After the transitional period (when every package places its
>   documentation under /usr/share/doc/<package>), we can find every
>   package documentation as /usr/share/doc/<package>.
> - At this time we can begin removing the symlinks when new packages
>   are uploaded.
> 
> 
> I would like to hear of better methods for a smooth transition, but I
> did not see any better solution yet (other ideas intend to tell the
> web sever to search both directories, but this doesn't help the user
> who is searching the correct directory).
> 
> 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
> 
> 
> --  
> To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 

-- 
Please cc all mailing list replies to me, also.
=========================================================================
* http://benham.net/index.html        <gecko@benham.net>           <><  *
* -------------------- * -----------------------------------------------*
* Debian Developer, Debian Project Secretary, Debian Webmaster          *
* <gecko@debian.org> <secretary@debian.org> <lintian-maint@debian.org>  *
* <webmaster@debian.org> <gecko@fortunet.com> <webmaster@spi-inc.org>   *
=========================================================================
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Joseph Carter <knghtbrd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #15 received at 40706@bugs.debian.org (full text, mbox):

From: Joseph Carter <knghtbrd@debian.org>
To: "Darren O. Benham" <gecko@debian.org>, 40706@bugs.debian.org
Cc: Roland Rosenfeld <roland@spinnaker.de>
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Sun, 4 Jul 1999 02:35:03 -0700
[Message part 1 (text/plain, inline)]
On Sat, Jul 03, 1999 at 06:44:57PM -0700, Darren O. Benham wrote:
> > This is principally the right way (according to FHS), but we cannot
> > recompile all packages now but we need a smooth way from one directory 
> > to the other.
> Why do we need a smooth way?  Some packages (including many of mine at the
> moment) are outta Policy compliance... If it's not a release critical bug,
> it doesn't have to be fixed before Potato goes out.
> 
> The FHS has a preferd way to make the transition... it's a symlink.  There
> might be reasons you don't want it on *your* computer, but what is wrong
> with that track as a default for Debian?

The problem with a single symlink between /usr/doc and /usr/share/doc is
that dpkg does Unwanted Things when you start installing packages through
simlinks and then move the files later.  This is one of the more than 550
bugs against dpkg.

WHat was proposed (symlinking individual directories) us the only
reasonable way to handle this until such time as the package manager can
handle the transition more sanely.  I will support the concept of this
proposal, but want to think on a few implementation details to eventually
eliminate the symlinks when we're ready.


I'm thinking something involving postinst and prerm making and removing
the symlinks conditionally and registering someplace that there is a
symlink for later removal, but I don't want to actually suggest it until
I have some idea what I'm talking abotu (I just woke up)

--
Joseph Carter <knghtbrd@debian.org>            Debian GNU/Linux developer
PGP: E8D68481E3A8BB77 8EE22996C9445FBE            The Source Comes First!
-------------------------------------------------------------------------
<ultima> netgod: My calculator has more registers than the x86, and
         -thats- sad
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roland Rosenfeld <roland@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #20 received at 40706@bugs.debian.org (full text, mbox):

From: Roland Rosenfeld <roland@debian.org>
To: "Darren O. Benham" <gecko@debian.org>
Cc: 40706@bugs.debian.org
Subject: Re: Bug#40706: /usr/share/doc vs. /usr/doc
Date: Sun, 4 Jul 1999 12:32:03 +0200
[Message part 1 (text/plain, inline)]
On Sat, 03 Jul 1999, Darren O. Benham wrote:

> > This is principally the right way (according to FHS), but we
> > cannot recompile all packages now but we need a smooth way from
> > one directory to the other.

> Why do we need a smooth way?

Because Debian is the distribution, where the user can upgrade or keep
every single package without any drawbacks. So we cannot expect the
user to upgrade every package from one stable to the next stable. And
I don't like the idea to re-build >3000 packages for all architectures
only to be FHS compliant. This will take much time and our next
release is delayed by now...

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.

> Some packages (including many of mine at the moment) are outta
> Policy compliance... If it's not a release critical bug, it doesn't
> have to be fixed before Potato goes out.

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)?

> The FHS has a preferd way to make the transition... it's a symlink.

Sorry, but I cannot find this in the FHS. What symlink are you talking 
about? One global symlink /usr/doc to /usr/share/doc? This causes two
problems (as someone pointed out in debian-devel):
- You have to "move" /usr/doc to /usr/share/doc first, which isn't
  trivial, because you cannot use a recursive "mv" as long as you can
  not be sure, that both directories are located on the same
  filesystem. On the other hand "cp -a" (or alternatives using tar)
  aren't optimal, because they temporary duplicate the disc usage of
  /usr/doc which may be more than the free disc space (204MB on my
  machine).
- There seem to be problems when installing a package which uses
  /usr/doc/<package> while /usr/doc is a symlink to /usr/share/doc. I
  don't exactly know what the problem is, but dpkg seems to have
  trouble with this (ask someone, who is more familiar with dpkg than
  me).

And if nevertheless decide to do it this way, there should be a
package introduce soon, which does this "move" before other packages
place their documentation in /usr/share/doc.

> There might be reasons you don't want it on *your* computer, but
> what is wrong with that track as a default for Debian?

See above (or tell me what other symlink you are talking about).

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
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Steve Greenland <stevegr@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #25 received at 40706@bugs.debian.org (full text, mbox):

From: Steve Greenland <stevegr@debian.org>
To: Roland Rosenfeld <roland@debian.org>, 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Sun, 4 Jul 1999 21:32:52 -0500
On 04-Jul-99, 05:32 (CDT), Roland Rosenfeld <roland@debian.org> wrote: 
> Because Debian is the distribution, where the user can upgrade or keep
> every single package without any drawbacks.
                       ^^^^^^^^^^^^^^^^^^^^^

Who says that? Agreed, users should not be forced to upgrade
unnecessarily, nor accross-the-board, and we should make that as
painlesl *as reasonably feasible*. But "without any drawbacks" is way
to strong a statement, one I don't think we've made, and one that is
impossible to accomplish. When we add/change a feature, we should
*attempt* to minimize the pain, but it is not unreasonable to expect
people to upgrade the affected packages to take advantage of that
feature.

> 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.

> 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 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. 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".

Steve
 


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Nicolás Lichtmaier <nick@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #30 received at 40706@bugs.debian.org (full text, mbox):

From: Nicolás Lichtmaier <nick@debian.org>
To: Steve Greenland <stevegr@debian.org>, 40706@bugs.debian.org
Cc: Roland Rosenfeld <roland@debian.org>
Subject: usr/share/doc vs. /usr/doc - Why don't we modify debhelper, etc..?
Date: Sun, 4 Jul 1999 23:59:52 -0300
 Why dpnt't we simply modify debhelper and similar tools to add this to
postinst of packages: (only if upgrading from a pre-FHS version)

if [ $1 = configure -a { $2 is a previous version than 1.2 } ]; then
	ln -sf ../share/$package /usr/doc/$package
fi

 And it would be just adding a

	dh_doc_hack 1.2   ( <- first version complying with FHS)

 to debian rules...


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roland Rosenfeld <roland@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #35 received at 40706@bugs.debian.org (full text, mbox):

From: Roland Rosenfeld <roland@debian.org>
To: Steve Greenland <stevegr@debian.org>, 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Mon, 5 Jul 1999 14:49:30 +0200
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


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Steve Greenland <stevegr@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #40 received at 40706@bugs.debian.org (full text, mbox):

From: Steve Greenland <stevegr@debian.org>
To: Roland Rosenfeld <roland@debian.org>, 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Mon, 5 Jul 1999 12:45:05 -0500
On 05-Jul-99, 07:49 (CDT), Roland Rosenfeld <roland@debian.org> wrote: 
> On Sun, 04 Jul 1999, Steve Greenland wrote:
> > 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.

But that's different than "without *any* drawbacks".

> 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).

No, they don't have to upgrade. They can choose between upgrading
a package, or accepting that for the packages they choose not
to upgrade, they'll have to continue to use /usr/doc/.

Actually, I'm not against the symlinks; I think they're a reasonable
idea. It's just that when people start tossing out statements that
sound like "Debian is committed to letting you continue to use the
four-year-old version of package x without *any* drawbacks", my alarms
go off. There *are* going to be drawbacks if a user chooses not to
upgrade some packages.

Steve



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roland Rosenfeld <roland@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #45 received at 40706@bugs.debian.org (full text, mbox):

From: Roland Rosenfeld <roland@debian.org>
To: Steve Greenland <stevegr@debian.org>
Cc: 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Mon, 5 Jul 1999 22:23:40 +0200
On Mon, 05 Jul 1999, Steve Greenland wrote:

> > > 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.
> 
> But that's different than "without *any* drawbacks".

English isn't my native language, so it can happen, that I'm not able
to exactly express what I mean...

> > 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).

> No, they don't have to upgrade. They can choose between upgrading a
> package, or accepting that for the packages they choose not to
> upgrade, they'll have to continue to use /usr/doc/.

Presumed that _all_ packages for _all_ architectures are FHS compliant 
at the moment we release 2.2.  I fear, that this isn't possible if we
want to release potato in the next half year.

So I still think that we need some interim solution until all packages 
are FHS compliant. And we should find this solution before the first
packages using /usr/share/doc are uploaded (I saw a lintian bug
report, where someone noted that his FHS compliant packages didn't
pass the lintian tests, so people already started using /usr/share/doc 
and we should find an interim solution soon).

> Actually, I'm not against the symlinks; I think they're a reasonable
> idea.

Good to hear. So we may have misunderstood each other because of my
language problems...

> It's just that when people start tossing out statements that sound
> like "Debian is committed to letting you continue to use the
> four-year-old version of package x without *any* drawbacks", my
> alarms go off.

That wasn't my intension. But you should keep in mind, that there are
still packages build in 1997 in slink (uudeview for example). So I
fear that it may take some time to move the complete distribution to
FHS. I fear that it will take at least one year until all packages are 
changed and I address this time.

I would prefer a way using postinst or dpkg to provide the symlinks to 
be able to remove them at some point in the future without uploading
all packages (with the symlink removed) again.

But at the moment I don't fully know how to do this in detail. We
should find a solution for this (which could be supported by
debhelper) soon.

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


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Richard Braakman <dark@xs4all.nl>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #50 received at 40706@bugs.debian.org (full text, mbox):

From: Richard Braakman <dark@xs4all.nl>
To: Roland Rosenfeld <roland@debian.org>, 40706@bugs.debian.org
Cc: Steve Greenland <stevegr@debian.org>
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Tue, 6 Jul 1999 15:05:23 +0200 (CEST)
Roland Rosenfeld wrote:
> So I still think that we need some interim solution until all packages 
> are FHS compliant. [...]

Frankly, I think we ended up doing it this way because there wasn't one.
There have been endless discussions about the best way to do this move,
with no resolution.  I'm glad we're finally just doing it.

Richard Braakman


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Steve Greenland <stevegr@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #55 received at 40706@bugs.debian.org (full text, mbox):

From: Steve Greenland <stevegr@debian.org>
To: 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Tue, 6 Jul 1999 21:25:30 -0500
On 05-Jul-99, 15:23 (CDT), Roland Rosenfeld <roland@debian.org> wrote: 
>
> Presumed that _all_ packages for _all_ architectures are FHS compliant 
> at the moment we release 2.2.  I fear, that this isn't possible if we
> want to release potato in the next half year.
> 
> [and] 
> 
> I would prefer a way using postinst or dpkg to provide the symlinks to 
> be able to remove them at some point in the future without uploading
> all packages (with the symlink removed) again.
> 
> But at the moment I don't fully know how to do this in detail. We
> should find a solution for this (which could be supported by
> debhelper) soon.

If you're concerned that packages won't be upgraded (new upload)
between now and the release of potato, how would doing anything with
postinst or debhelper do anything for us? (Agreed, debhelper needs to
be updated to use /usr/share/doc, but not everybody uses debhelper.) If
a package get's uploaded, there is no excuse for not moving things to
/usr/share/doc, as it's trivial change in the rules file.

(Yes there are other FHS issues that are harder to deal with, but we
aren't discussing them here.)

Steve




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roland Rosenfeld <roland@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #60 received at 40706@bugs.debian.org (full text, mbox):

From: Roland Rosenfeld <roland@debian.org>
To: Steve Greenland <stevegr@debian.org>, 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Wed, 7 Jul 1999 14:04:04 +0200
On Tue, 06 Jul 1999, Steve Greenland wrote:

> > I would prefer a way using postinst or dpkg to provide the
> > symlinks to be able to remove them at some point in the future
> > without uploading all packages (with the symlink removed) again.

> > But at the moment I don't fully know how to do this in detail. We
> > should find a solution for this (which could be supported by
> > debhelper) soon.

> If you're concerned that packages won't be upgraded (new upload)
> between now and the release of potato, how would doing anything with
> postinst or debhelper do anything for us? (Agreed, debhelper needs
> to be updated to use /usr/share/doc, but not everybody uses
> debhelper.)

My idea (please note, this is only a first idea and there may be some
difficulties with which should be fixed) is, that the new (FHS aware)
debhelper could add something in postinst, which creates a symlink
/usr/doc/<package> pointing to /usr/share/doc/<package> if (and only
if) there is no special "flag" file (a conffile) which tells postinst,
that this system is fully FHS compliant. In addition to this postrm
should remove this symlink if it exists.

With this we have the following four stages:

1. The actual state: All documentation is located in /usr/doc and all
   package documentation is accessible as /usr/doc/<package>

2. The migration stage: Old packages are still available in
   /usr/doc/<package>, new packages install their documentation as
   /usr/share/doc/<package>, but the symlinks created in postinst make 
   the documentation of the new packages accessible as
   /usr/doc/<package>.

3. The "migration complete" state: Now every package is upgraded to
   FHS, which means, that the package documentations can now be
   accessed as /usr/share/doc/<package> and additionally via the
   symlinks /usr/doc/<package>. Now the symlinks are superfluously and
   should be removed. If the symlinks would be part of the packages,
   we couldn't remove them, but if they are created by the postinst
   scripts, we can now remove them and create some kind of "flag"
   file, which tells newly installed packages that they do not have to
   install these symlinks from now on. This "flag" can also be used to
   tell web servers etc. that they should look for the documentation
   in /usr/share/doc from now on instead of /usr/doc.
   
4. The "after migration" state: When the migration is done, debhelper
   can be changed to stop creating the postinst/postrm entries, which
   create the symlinks, because they are no longer needed.


Does this sound reasonable?

> If a package get's uploaded, there is no excuse for not moving
> things to /usr/share/doc, as it's trivial change in the rules file.

Correct. But I want to have some kind of smooth migration which isn't
possible if you simply install the documentation of new packages in
/usr/share/doc without any other changes like the symlinks above.
 
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


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #65 received at 40706@bugs.debian.org (full text, mbox):

From: Santiago Vila <sanvila@unex.es>
To: Roland Rosenfeld <roland@debian.org>, 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Wed, 7 Jul 1999 16:20:46 +0200 (CET)
On Wed, 7 Jul 1999, Roland Rosenfeld wrote:

> With this we have the following four stages:
> 
> [snipped]

For people not using helper tools (there are many of them), this means
*double* work for every package, because you have first to provide
symlinks and then you have to remove them.

I do not think it is reasonable.

The FHS migration will be painful enough so that we have to make it
twice. Better to do it at a time (on a per package basis), only *once*.

I would much prefer some sort of "light" release goal (i.e. not to be
interpreted very strictly). For example: "We will try to make all base and
priority >= standard packages in potato to use /usr/share/doc instead of
/usr/doc".

-- 
 "7119841ee3dabf13c3e35e053f7e6f09" (a truly random sig)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roland Rosenfeld <roland@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #70 received at 40706@bugs.debian.org (full text, mbox):

From: Roland Rosenfeld <roland@debian.org>
To: Santiago Vila <sanvila@unex.es>
Cc: 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Wed, 7 Jul 1999 16:51:42 +0200
On Wed, 07 Jul 1999, Santiago Vila wrote:

> > With this we have the following four stages:

> For people not using helper tools (there are many of them), this
> means *double* work for every package, because you have first to
> provide symlinks and then you have to remove them.
> 
> I do not think it is reasonable.

I see the problem, but I don't see an alternative proposal.
Do you think that all packages will be converted to FHS before
releasing potato? This is my preferred solution, but I don't think
that it is really possible to convert all packages for all
architectures soon.

> The FHS migration will be painful enough so that we have to make it
> twice. Better to do it at a time (on a per package basis), only
> *once*.

I prefer some pain to us developers in contrast to the pain to the
users who have to search for every single package documentation, if we 
use two directories for this in parallel.

> I would much prefer some sort of "light" release goal (i.e. not to
> be interpreted very strictly). For example: "We will try to make all
> base and priority >= standard packages in potato to use
> /usr/share/doc instead of /usr/doc".

This doesn't really help the user searching for documentation. He
still has to search both directories for the documentation, if he
doesn't know which packages are priority >= standard (I personally
don't know this for most packages).

I prefer a release "light" goal, like this: "Every package
documentation can be accessed as /XXX/<package>" (where XXX is a
constant for _all_ packages). This was true for slink and I think it
should be true for potato, too. Otherwise potato will be worse than
slink and IMHO we shouldn't step back...

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


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #75 received at 40706@bugs.debian.org (full text, mbox):

From: Santiago Vila <sanvila@unex.es>
To: Roland Rosenfeld <roland@debian.org>
Cc: 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Wed, 7 Jul 1999 17:38:04 +0200 (CET)
On Wed, 7 Jul 1999, Roland Rosenfeld wrote:

> On Wed, 07 Jul 1999, Santiago Vila wrote:
> 
> > > With this we have the following four stages:
> 
> > For people not using helper tools (there are many of them), this
> > means *double* work for every package, because you have first to
> > provide symlinks and then you have to remove them.
> > 
> > I do not think it is reasonable.
> 
> I see the problem, but I don't see an alternative proposal.
> Do you think that all packages will be converted to FHS before
> releasing potato?

No, I don't think *all* packages will be converted. Of course not.

> This is my preferred solution, but I don't think
> that it is really possible to convert all packages for all
> architectures soon.

However, if we convert 90%, 80% or just 20% of them (if the most popular
ones are included in that 20%), then it would not be such a disaster, IMHO.

> > The FHS migration will be painful enough so that we have to make it
> > twice. Better to do it at a time (on a per package basis), only
> > *once*.
> 
> I prefer some pain to us developers in contrast to the pain to the
> users who have to search for every single package documentation, if we 
> use two directories for this in parallel.

Please, multiply whatever pain by the number of packages in the
distribution. Having to look to /usr/doc as well as /usr/share/doc is
not such a great inconvenience, after all.

> > I would much prefer some sort of "light" release goal (i.e. not to
> > be interpreted very strictly). For example: "We will try to make all
> > base and priority >= standard packages in potato to use
> > /usr/share/doc instead of /usr/doc".
> 
> This doesn't really help the user searching for documentation. He
> still has to search both directories for the documentation, if he
> doesn't know which packages are priority >= standard (I personally
> don't know this for most packages).

I think it would help.

The point is that packages which are priority >= standard tend to be quite
"popular" (in the sense that many people have them installed). We could
set as a goal to convert those packages (which are only a few, compared to
the thousands the complete distribution has), and then we could be
almost sure that many of the packages installed in a typical system
would be already converted.

It would help because /usr/doc could become almost empty *for a typical
system*. (Not if you install the 2500+ packages, of course).

> I prefer a release "light" goal, like this: "Every package
> documentation can be accessed as /XXX/<package>" (where XXX is a
> constant for _all_ packages). This was true for slink and I think it
> should be true for potato, too. Otherwise potato will be worse than
> slink and IMHO we shouldn't step back...

It is not a light goal if it takes double work to everybody.

We could have some sort of FHS-threshold for the release:

"We will not release until 90% of all priority >= standard packages are
converted to use /usr/share/doc" or else "we will not release until 80% of
the 300 most popular packages are converted to use /usr/share/doc".

-- 
 "daf503f1660a0508645a16cbce42a559" (a truly random sig)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roland Rosenfeld <roland@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #80 received at 40706@bugs.debian.org (full text, mbox):

From: Roland Rosenfeld <roland@debian.org>
To: Santiago Vila <sanvila@unex.es>
Cc: 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Wed, 7 Jul 1999 18:54:51 +0200
On Wed, 07 Jul 1999, Santiago Vila wrote:

> However, if we convert 90%, 80% or just 20% of them (if the most
> popular ones are included in that 20%), then it would not be such a
> disaster, IMHO.

IMHO only 0% or 100% aren't a disaster. Everything else is annoying,
at least for me as a user.

But it seems that I am the only one who has a problem with this, so
maybe I should simply sleep for approximately a year, hoping that
everything is converted to FHS in this time...

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


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joey@kitenet.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #85 received at 40706@bugs.debian.org (full text, mbox):

From: Joey Hess <joey@kitenet.net>
To: Santiago Vila <sanvila@unex.es>, 40706@bugs.debian.org
Cc: Roland Rosenfeld <roland@debian.org>
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Wed, 7 Jul 1999 11:26:21 -0700
Santiago Vila wrote:
> For people not using helper tools (there are many of them), this means
> *double* work for every package, because you have first to provide
> symlinks and then you have to remove them.

It can be pretty easy to do. Make an update-doc-symlinks script, that takes
a single (add/remove) parameter and you only have to add 1 line of code to
postinst and postrm.

-- 
see shy jo


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to ron@microtronics.com.au (Ron):
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #90 received at 40706@bugs.debian.org (full text, mbox):

From: ron@microtronics.com.au (Ron)
To: 40706@bugs.debian.org
Cc: debian-policy@lists.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Thu, 8 Jul 1999 05:35:46 +0930 (CST)
> It would help because /usr/doc could become almost empty *for a typical
> system*. (Not if you install the 2500+ packages, of course).

..actually this is almost exactly the *problem* that this change is
going to cause one of my debian boxes.

I have a box that uses several smallish drives..  some time ago when
my /usr partition was beginning to look rather full I split /usr/src
and /usr/doc off onto a separate drive (and partitions of their own).

So now _my_ problem is that if /usr/doc is slowly migrated to /usr/share
my /usr partition will again overflow long before the change is complete
and meanwhile I will have an increasingly empty partition that I won't
be able to immediately reuse.

What I had hoped I could do in this case would be simply to remount
the /usr/doc partition as /usr/share/doc and then symlink /usr/doc
to it..  however it was previously indicated that this might cause
problems with dpkg..

Could someone please elaborate on what sort of problems they see
this may be likely to cause?  If I can reasonably make this switch
before I have files in both doc locations then I'll certainly be
able to breathe easier whatever else happens ;-)

thanks,
Ron.


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <rhertzog@hrnet.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #95 received at 40706@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <rhertzog@hrnet.fr>
To: Santiago Vila <sanvila@unex.es>, 40706@bugs.debian.org
Cc: Roland Rosenfeld <roland@debian.org>
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Wed, 7 Jul 1999 20:15:15 +0200
Le Wed, Jul 07, 1999 at 05:38:04PM +0200, Santiago Vila écrivait:
> We could have some sort of FHS-threshold for the release:
> 
> "We will not release until 90% of all priority >= standard packages are
> converted to use /usr/share/doc" or else "we will not release until 80% of
> the 300 most popular packages are converted to use /usr/share/doc".

I agree with Manoj and with Richard, there is no perfect solution, but
we'll have to do it so let's go with it.

Cheers,
-- 
Hertzog Raphaël >> 0C4CABF1 >> http://prope.insa-lyon.fr/~rhertzog/


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Richard Braakman <dark@xs4all.nl>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #100 received at 40706@bugs.debian.org (full text, mbox):

From: Richard Braakman <dark@xs4all.nl>
To: Ron <ron@microtronics.com.au>
Cc: 40706@bugs.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Wed, 7 Jul 1999 23:41:46 +0200 (CEST)
Ron wrote:
> What I had hoped I could do in this case would be simply to remount
> the /usr/doc partition as /usr/share/doc and then symlink /usr/doc
> to it..  however it was previously indicated that this might cause
> problems with dpkg..

The best thing to do is probably to make sure that /usr/doc/ and
/usr/share/doc end up on the same filesystem, but in separate
directories.

Making a symlink from /usr/doc to this filesystem should be no
problem.  Dpkg was designed to work well with that kind of symlinking
(which is why its behaviour is often counterintuitive to us
developers).

Symlinking /usr/doc directly to /usr/share/doc is likely to break
things, though, since dpkg will be moving files from one to the other
without realizing that they are the same directory.

Richard Braakman


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Nicolás Lichtmaier <nick@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #105 received at 40706@bugs.debian.org (full text, mbox):

From: Nicolás Lichtmaier <nick@debian.org>
To: Roland Rosenfeld <roland@debian.org>, 40706@bugs.debian.org
Cc: Steve Greenland <stevegr@debian.org>
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Thu, 8 Jul 1999 01:59:04 -0300
> My idea (please note, this is only a first idea and there may be some
> difficulties with which should be fixed) is, that the new (FHS aware)
> debhelper could add something in postinst, which creates a symlink
> /usr/doc/<package> pointing to /usr/share/doc/<package> if (and only
> if) there is no special "flag" file (a conffile) which tells postinst,
> that this system is fully FHS compliant. In addition to this postrm
> should remove this symlink if it exists.


 (Copying from previous message in this thread =/ )

 Why dont't we simply modify debhelper and similar tools to add this to
postinst of packages: (only if upgrading from a pre-FHS version)

if [ $1 = configure -a { $2 is a previous version than 1.2 } ]; then
        ln -sf ../share/$package /usr/doc/$package
fi

 And it would be just adding a

        dh_doc_hack 1.2   ( <- first version complying with FHS)

 to debian rules...

 This would mean that the symlinks would only be created the first time the
user replaces a FSSTND package with a FHS package. Later the user could
always remove that script. I propose too that new (initialy released
complying with FHS) packages do a:

 if [ -d /usr/doc ]; then ln -sf ../share/doc/$package /usr/doc/$package ; fi

 So a user would be able to just rm -rf /usr/doc sometime in the future...


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #110 received at 40706@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: 08 Jul 1999 10:46:30 -0500
Hi,
>>"Richard" == Richard Braakman <dark@xs4all.nl> writes:

 Richard> The best thing to do is probably to make sure that /usr/doc/ and
 Richard> /usr/share/doc end up on the same filesystem, but in separate
 Richard> directories.

        Umm, how do we do that? We have really no control over how the
 sys admin does partitioning ...

        manoj

-- 
 The camel has a single hump; The dromedary two; Or else the other way
 around. I'm never sure.  Are you? Ogden Nash
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


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Joseph Carter <knghtbrd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #115 received at 40706@bugs.debian.org (full text, mbox):

From: Joseph Carter <knghtbrd@debian.org>
To: Manoj Srivastava <srivasta@debian.org>, 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Thu, 8 Jul 1999 15:09:01 -0700
[Message part 1 (text/plain, inline)]
On Thu, Jul 08, 1999 at 10:46:30AM -0500, Manoj Srivastava wrote:
> 
>  Richard> The best thing to do is probably to make sure that /usr/doc/ and
>  Richard> /usr/share/doc end up on the same filesystem, but in separate
>  Richard> directories.
> 
>         Umm, how do we do that? We have really no control over how the
>  sys admin does partitioning ...

True, however the issue is someone saying that their system will have
problems with /usr/doc and /usr/share/doc on seperate filesystems.  The
answer "put them on the same filesystem then" makes perfect sense.  And
it's quite simply done---take the existing /usr/doc and mount it as
/usr/share/doc, make a subdir in it, and move everything into it.  Then
just put a /usr/doc symlink into place.

This isn't something that can be done by us---it has to be done by the
sysadmin.  Only they can know how they have to manage filesystems.  No
more than Debian can be responsible for mounting most of /var into a
subdir under /usr because that's where there's room for it until such time
as I have more drive space..  *waves hi to bma*

All we can do is try not to break other things.  Leave where I have to put
parts of /var to me and where he has to put /usr/doc to him.

-- 
Joseph Carter <knghtbrd@debian.org>            Debian GNU/Linux developer
PGP: E8D68481E3A8BB77 8EE22996C9445FBE            The Source Comes First!
-------------------------------------------------------------------------
<Overfiend> Thunder-: when you get { MessagesLikeThisFromYourHardDrive }
<Overfiend> Thunder-: it either means { TheDriverIsScrewy }
<Overfiend> or
<Overfiend> { YourDriveIsFlakingOut BackUpYourDataBeforeIt'sTooLate
            PrayToGod }

[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to ron@microtronics.com.au (Ron):
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #120 received at 40706@bugs.debian.org (full text, mbox):

From: ron@microtronics.com.au (Ron)
To: Manoj Srivastava <srivasta@debian.org>, 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Fri, 9 Jul 1999 08:12:50 +0930 (CST)
> >>"Richard" == Richard Braakman <dark@xs4all.nl> writes:
> 
>  Richard> The best thing to do is probably to make sure that /usr/doc/ and
>  Richard> /usr/share/doc end up on the same filesystem, but in separate
>  Richard> directories.
> 
>         Umm, how do we do that? We have really no control over how the
>  sys admin does partitioning ...
> 
>         manoj

This was a DIY solution to a situation I unwittingly created on one of my
debian boxen by putting /usr/doc on its own partiton to save an overflowing
/usr

I don't think Richard intended that anything special should be done by
Debian with regard to this ;-)

best,
Ron.


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Richard Braakman <dark@xs4all.nl>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #125 received at 40706@bugs.debian.org (full text, mbox):

From: Richard Braakman <dark@xs4all.nl>
To: Manoj Srivastava <srivasta@debian.org>, 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Fri, 9 Jul 1999 00:39:02 +0200 (CEST)
Manoj Srivastava wrote:
> Hi,
> >>"Richard" == Richard Braakman <dark@xs4all.nl> writes:
> 
>  Richard> The best thing to do is probably to make sure that /usr/doc/ and
>  Richard> /usr/share/doc end up on the same filesystem, but in separate
>  Richard> directories.
> 
>         Umm, how do we do that? We have really no control over how the
>  sys admin does partitioning ...

I was speaking to the sysadmin :-)

I think Debian should just move the files.  I don't trust any of the
symlinking proposals.  It may work in the usual case, but what happens
with downgrades?  With aborted installs?  dpkg was designed to reserve
that kind of symlink for the system administrator.

Richard Braakman


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to William Ono <wmono@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #130 received at 40706@bugs.debian.org (full text, mbox):

From: William Ono <wmono@debian.org>
To: 40706@bugs.debian.org
Cc: debian-policy@lists.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Fri, 16 Jul 1999 13:11:36 -0700 (PDT)
> On 16 Jul 1999, Manoj Srivastava wrote:
> >         I propose that there be a syymlink from /usr/doc/<package> ->
> >  /usr/share/doc/<package>, managed by the p[ackage itself.

On Fri, 16 Jul 1999, Santiago Vila wrote:
> Symlinking /usr/doc/<package> to /usr/share/doc/<package> directly
> is not supported by dpkg, so additional and ugly tweaks would be required
> in maintainer scripts.

I believe the problem Santiago brings up is that dpkg will become confused
by files appearing in both /usr/doc/package and /usr/share/doc/package,
through the symlink.  If this is the case, can we amend the proposal to
symlink /usr/doc/package_FHS -> /usr/share/doc/package ?  (The exact name
is of course up for discussion.)  This should avoid that problem, and the
symlink in /usr/doc should be easy enough to find.

I admit that I am not a dpkg expert; I have probably misunderstood the
problem, as the solution seems too simple not to have been found
previously.

Thanks.

-- 
William Ono <wmono@debian.org>                             PGP key: 0x93BA6AFD
 fingerprint = E3 64 C5 43 3E B3 2D A6  C6 D7 E3 45 90 24 78 DE = fingerprint
PGP-encrypted mail welcome!           "640k ought to be enough for everybody."




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #135 received at 40706@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: 16 Jul 1999 15:50:46 -0500
Hi,
>>"William" == William Ono <wmono@debian.org> writes:

 William> I believe the problem Santiago brings up is that dpkg will
 William> become confused by files appearing in both /usr/doc/package
 William> and /usr/share/doc/package, through the symlink.

        Really? Can you provide details, please? I know dpkg has
 problems when *replacing* a symlink with a dir, or vice versa,
 but in this case (with the symlink created in postinst, and removed
 in postrm) dpkg is never aware of the symlink, and should have no
 problems whatsoever.

        manoj

-- 
 "The less you know about home computers the more you'll want the new
 IBM PS/1." Advertisment in the Edmonton Journal, Thursday, December
 13, 1990
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


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to William Ono <wmono@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #140 received at 40706@bugs.debian.org (full text, mbox):

From: William Ono <wmono@debian.org>
To: 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Fri, 16 Jul 1999 16:21:24 -0700 (PDT)
>  William> I believe the problem Santiago brings up is that dpkg will
>  William> become confused by files appearing in both /usr/doc/package
>  William> and /usr/share/doc/package, through the symlink.

On 16 Jul 1999, Manoj Srivastava wrote:
>         Really? Can you provide details, please?

Sorry, no, I can't provide details.  I accepted Santiago's problem as
existing before suggesting a work-around; as I said below this comment, I
am no dpkg expert and don't know how well it handles symlinks at all.

If this problem does not exist, then the work-around does not need to
exist either.  I withdraw my suggestion.

Thanks.

-- 
William Ono <wmono@debian.org>                             PGP key: 0x93BA6AFD
 fingerprint = E3 64 C5 43 3E B3 2D A6  C6 D7 E3 45 90 24 78 DE = fingerprint
PGP-encrypted mail welcome!           "640k ought to be enough for everybody."



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Joseph Carter <knghtbrd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #145 received at 40706@bugs.debian.org (full text, mbox):

From: Joseph Carter <knghtbrd@debian.org>
To: William Ono <wmono@debian.org>
Cc: 40706@bugs.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Fri, 16 Jul 1999 16:50:43 -0700
[Message part 1 (text/plain, inline)]
On Fri, Jul 16, 1999 at 01:11:36PM -0700, William Ono wrote:
> > Symlinking /usr/doc/<package> to /usr/share/doc/<package> directly
> > is not supported by dpkg, so additional and ugly tweaks would be required
> > in maintainer scripts.
> 
> I believe the problem Santiago brings up is that dpkg will become confused
> by files appearing in both /usr/doc/package and /usr/share/doc/package,
> through the symlink.  If this is the case, can we amend the proposal to
> symlink /usr/doc/package_FHS -> /usr/share/doc/package ?  (The exact name
> is of course up for discussion.)  This should avoid that problem, and the
> symlink in /usr/doc should be easy enough to find.

This would happen if the symlink were part of the package.  If it is
handled in postinst/prerm OTOH, the dpkg issue would be a non-issue.

-- 
Joseph Carter <knghtbrd@debian.org>             Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--------------------------------------------------------------------------
<SilverStr> media ethics is an oxymoron, much like Jumbo Shrimp and
            Microsoft Works.
<MonkAway> not to mention NT Security

[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #150 received at 40706@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: 40706@bugs.debian.org
Cc: control@bugs.debian.org
Subject: [AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: 17 Jul 1999 01:08:13 -0500
retitle 40706 [AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
thanks

    PROPOSAL: Easing the transition from `/usr/doc' to `/usr/share/doc'
    -------------------------------------------------------------------

                  Manoj Srivastava <srivasta@debian.org>
                             $Revision: 1.3 $


-------------------------------------------------------------------------------


Copyright Notice
----------------

     Copyright © 1998 by Manoj Srivastava.

     You are given permission to redistribute this document and/or modify
     it under the terms of the GNU General Public License as published by
     the Free Software Foundation; either version 2, or (at your option)
     any later version.

     On Debian GNU/Linux systems, the complete text of the GNU General
     Public License can be found in `</usr/share/common-licenses/GPL>'.


-------------------------------------------------------------------------------


1. Introduction, and Administrivia
----------------------------------


1.1. Deadline for tabling the discussion
----------------------------------------

     I decided to use the suggested _usual_ period of two weeks for this
     proposal. Therefore, this proposal needs to be acted upon before July
     31th, 1999.


1.2. People Seconding the Proposal
----------------------------------

     The following people have seconded the proposal so far, and there has
     been one objection.

     1.   Joey Hess <joey@kitenet.net>

     2.   Darren O. Benham <gecko@debian.org>

     3.   Roland Rosenfeld <roland@spinnaker.de>

     The person who objected was Santiago Vila <sanvila@unex.es>


-------------------------------------------------------------------------------


2. Need for a mechanism to ease the change
------------------------------------------

     Now that we have formally decided to adopt the FHS, we need to ensure
     the transition is as smooth as we can make it. We can not just mandate
     that the distribution migrate to the new standard, and expect to leave
     it at that, since the unit of updates in the distribution is the
     package, and FHS conformance thus has to be achieved package by
     package. There is also the consideratiuon that evolutionalry changes
     are less dangerous, and easier to stage, than revolutionary changes,
     which tend to be a tad more messy.

     Some of the constraints are:

        * The transition may take a long time, going by previous
          transitions, and not all packages are upgraded anywhere near
          simultaneously.

          I think that expecting _*all*_ packages to have moved before we
          release potato is futile, unless we do not plan on releasing
          potato for 18 months or so. We *_cannot_* expect to get FHS
          compliance in place by potato.

        * We should not break backwards compatibility during the transition
          period. This is a quality of implementation issue

          During the transition, we need to provide backwards
          compatibility, firstly for programs ike `dwww', and `dhelp', and
          also for our users who have gotten used to looking under a single
          dir (`/usr/doc/') for docs (`/usr/doc/`package''). During the
          transition, the documentation could be in in two places, and that
          is not good


-------------------------------------------------------------------------------


3. Proposed solution
--------------------

     I propose that there be a syymlink from /usr/doc/package =>
     /usr/share/doc/package, managed by the package itself. Since there is
     some concern that the packaging system does not deal well with
     replacing a directory with a symbolic link, it is suggested that the
     link be manipulated in the maintainer scripts postinst and postrm.

          	  Postinst install:
          if [ -d /usr/doc ]; then
            if [ ! -e /usr/doc/$package ]; then
              (cd /usr/doc;
               if [ -d ../share/doc/$package ]; then
                  ln -s ../share/doc/$package $package ;
               fi
              )
            fi
          fi

          postrm remove:
          if [ -d /usr/doc ]; then
            if [ -L /usr/doc/$package ]; then
              rm /usr/doc/$package ;
            fi
          fi

     This is how it works:

     1.   Policy 3.X mandates that packages that move the docs to
          /usr/share/doc must provide a compatibility symlink in /usr/doc.
          This shall allow packages to incrementally move to policy 3.X,
          while providing compatibility with older systems.
          (/usr/doc/package symlink is handled by package)

     2.   At a later date, another policy (say, 4.X) shall ask for packages
          to no longer provide the link. We can do this when we are sure
          the time for the links is gone, and the transitions is over.

     I understand that the forest of symlinks is ugly, but it is
     technically sound, it maintains backwards compatibility, it allows
     incremental compliance to FHS, and caters to a hybrid system. I submit
     that aesthetics takes a back seat to functionality.

     To the objection that it shall cause package to be modified twice, I
     say that

        * This is a complex transition, and may require this to meet the
          constraints of tehsituation

        * One modification of the packages is required anyway for comliance
          with the FHS.

        * The second modification, namely, the removal of the symbolic
          link, shall be well into the future, and added to a future policy
          change. It is concievable that the packages may need to change
          for policy updates in any case.


-------------------------------------------------------------------------------


     PROPOSAL: Easing the transition from `/usr/doc' to `/usr/share/doc'
     Manoj Srivastava <srivasta@debian.org>
     $Revision: 1.3 $


-- 
 "If you don't make money off of it, it had better be either a
 religious experience or a hobby." Lance Cooper
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


Changed bug title. Request was from Manoj Srivastava <srivasta@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Joseph Carter <knghtbrd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #157 received at 40706@bugs.debian.org (full text, mbox):

From: Joseph Carter <knghtbrd@debian.org>
To: 40706@bugs.debian.org
Subject: Re: Bug#40706: [AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: Sat, 17 Jul 1999 01:36:16 -0700
[Message part 1 (text/plain, inline)]
In the interests of seeing a solution to this problem happen soon and
before anymore maintainers take it upon themselves to decide how the
/usr/share/doc migration should happen, I second Manoj's proposal.  I
would prefer the symlinks be managed seperately from the package that
needs them, but upon asking myself the ultimate question ("why?") I could
not come up with a good reason.

-- 
Joseph Carter <knghtbrd@debian.org>             Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--------------------------------------------------------------------------
California, n.:
    From Latin "calor", meaning "heat" (as in English "calorie" or
Spanish "caliente"); and "fornia'" for "sexual intercourse" or
"fornication." Hence: Tierra de California, "the land of hot sex."
        -- Ed Moran

[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Stefan Gybas <cab@studbox.uni-stuttgart.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #162 received at 40706@bugs.debian.org (full text, mbox):

From: Stefan Gybas <cab@studbox.uni-stuttgart.de>
To: 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Sat, 17 Jul 1999 20:18:41 +0200
Roland Rosenfeld wrote:

> If there really is a technical problem with this link as mentioned by
> Santiago (I didn't check this myself), we can handle this symlink in
> postinst:

I second this proposal (I mean the whole symlink proposal, not just this
addition).

-- 
Stefan Gybas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to William Ono <wmono@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #167 received at 40706@bugs.debian.org (full text, mbox):

From: William Ono <wmono@debian.org>
To: 40706@bugs.debian.org
Subject: Re: Bug#40706: [AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: Sat, 17 Jul 1999 18:59:34 -0700 (PDT)
-----BEGIN PGP SIGNED MESSAGE-----

On 17 Jul 1999, Manoj Srivastava wrote:

>     PROPOSAL: Easing the transition from `/usr/doc' to `/usr/share/doc'
>     -------------------------------------------------------------------
> 
>                   Manoj Srivastava <srivasta@debian.org>
>                              $Revision: 1.3 $

I second this proposal.
  
- -- 
William Ono <wmono@debian.org>                             PGP key: 0x93BA6AFD
 fingerprint = E3 64 C5 43 3E B3 2D A6  C6 D7 E3 45 90 24 78 DE = fingerprint
PGP-encrypted mail welcome!           "640k ought to be enough for everybody."

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQEVAwUBN5E04jZejXGTumr9AQHTNwgAmaj6ELPK4sKtyYwwaXvsMndhEh6qSTgR
zyWkvGPMtEn148CHtirC2dNrnJn1lfN8UsXkmGG27Ddly5SZ7Ort9mb3X6o5FUsN
egGQsqPmSKq5DrWmo64sCkMeHOmC3F7mljNvX9a1qYj8gYymrf6ycbIDamKMg+8o
gaU23RdsYI7Hta6P6JwqsQ1tfT63ssLWwWxmjKCLvLA+vHn+lfam5ZnCYB9XR0Mg
+FeMrWlFIA0TMyC3eyGH0vNqzrVVD25/D4Cj7hjl5vzDEgTSnbXE715XsMBpWDUG
waALHS5p1PE0sIX/NeRjxPKa/+4dzLhaDirvYHFowuwFUAp4GnMJBg==
=h1iT
-----END PGP SIGNATURE-----



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Nicolás Lichtmaier <nick@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #172 received at 40706@bugs.debian.org (full text, mbox):

From: Nicolás Lichtmaier <nick@debian.org>
To: Manoj Srivastava <srivasta@debian.org>, 40706@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Programs that need to access every doc in the system.
Date: Sun, 18 Jul 1999 09:06:26 -0300
 Programs which need to refer to all Debian docs should then still be
pointing to /usr/doc, until the migration is nearly complete. I'm talking
about apache ( /doc/ ), dhelp, etc.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #177 received at 40706@bugs.debian.org (full text, mbox):

From: Santiago Vila <sanvila@unex.es>
To: Manoj Srivastava <srivasta@debian.org>, 40706@bugs.debian.org
Subject: Re: Bug#40706: [AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: Mon, 19 Jul 1999 15:27:38 +0200 (CET)
On 17 Jul 1999, Manoj Srivastava wrote:

>         * We should not break backwards compatibility during the transition
>           period. This is a quality of implementation issue
> 
>           During the transition, we need to provide backwards
>           compatibility, firstly for programs ike `dwww', and `dhelp', and
>           also for our users who have gotten used to looking under a single
>           dir (`/usr/doc/') for docs (`/usr/doc/`package''). During the
>           transition, the documentation could be in in two places, and that
>           is not good

Please note that when we switched from /usr/doc/copyright/package to
/usr/doc/package/copyright we didn't create any smylinks "for backwards
compatibility".

I understand that programs like dwww or dhelp will have to look
in both directories, but this may be done without the symlinks.

So, the *only* remaining reason for the symlinks is the users who have
gotten used to look under /usr/doc. Well, they will have to get used to
look under /usr/share/doc sooner or later, so this will not help very
much. This proposal would just postpone the time when people will have to
look at /usr/share/doc.

By comparison, it is not so much inconvenience to look at /usr/share/doc
and /usr/doc when manually looking for documentation, because when a user
finds what he/she is looking for, ordinarily he/she concentrates on
actually *reading* the docs, so the actual place where to find the docs
is not so much important as long as the docs are there.

Thanks.

-- 
 "131411fd05cc5ce33188a44fb66432bd" (a truly random sig)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #182 received at 40706@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: Santiago Vila <sanvila@unex.es>
Cc: 40706@bugs.debian.org
Subject: Re: Bug#40706: [AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: 19 Jul 1999 11:00:35 -0500
Hi,
>>"Santiago" == Santiago Vila <sanvila@unex.es> writes:

 Santiago> Please note that when we switched from
 Santiago> /usr/doc/copyright/package to /usr/doc/package/copyright we
 Santiago> didn't create any smylinks "for backwards compatibility".

        The copyrights are accessed far less frequently than the
 documentation is. It is more irritating if one looks in
 /usr/doc/package, does not find stuff, and has to look in the other
 place, several times. Quality of implementation dictates we try to
 make common cases work as they did before. 


 Santiago> I understand that programs like dwww or dhelp will have to look
 Santiago> in both directories, but this may be done without the symlinks.

        The mainatinaers would probably appreciate a patch, or
 something. dhelp has been changed to only look at /usr/share/doc,
 which I think is premature.

 Santiago> So, the *only* remaining reason for the symlinks is the
 Santiago> users who have gotten used to look under /usr/doc. Well,
 Santiago> they will have to get used to look under /usr/share/doc
 Santiago> sooner or later, so this will not help very much. This
 Santiago> proposal would just postpone the time when people will have
 Santiago> to look at /usr/share/doc.

        You are missing the point. It would be acceptable when one can
 look at any *one* directory. Whtehter it is /usr/doc or
 /usr/share/doc does not really matter. The problem is the )long)
 period of transition, where one has to look at two different places. 

        You seem to be gnoring the time of transition.

        manoj
-- 
 Intuition, however illogical, is recognized as a command
 prerogative. Kirk, "Obsession", stardate 3620.7
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


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #187 received at 40706@bugs.debian.org (full text, mbox):

From: Santiago Vila <sanvila@unex.es>
To: Manoj Srivastava <srivasta@debian.org>
Cc: 40706@bugs.debian.org
Subject: Re: Bug#40706: [AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: Mon, 19 Jul 1999 20:02:54 +0200 (CET)
On 19 Jul 1999, Manoj Srivastava wrote:

> >>"Santiago" == Santiago Vila <sanvila@unex.es> writes:
> 
>  Santiago> So, the *only* remaining reason for the symlinks is the
>  Santiago> users who have gotten used to look under /usr/doc. Well,
>  Santiago> they will have to get used to look under /usr/share/doc
>  Santiago> sooner or later, so this will not help very much. This
>  Santiago> proposal would just postpone the time when people will have
>  Santiago> to look at /usr/share/doc.
> 
>         You are missing the point. It would be acceptable when one can
>  look at any *one* directory. Whtehter it is /usr/doc or
>  /usr/share/doc does not really matter. The problem is the )long)
>  period of transition, where one has to look at two different places.

But your proposed solution creates an inmense lot of work for everybody,
just to keep compliance with a standard (FSSTND) which is not the one that
we should follow. Every postinst has to be modified. Every postrm has to
be modified. Multi-binary packages will have to be modified a lot, and in
many cases maintainer scripts that never existed before will have to be
created as new and installed by debian/rules.

This is a high price to pay, very high.

We have a standard documentation format, which is HTML. People is free of
course to cd to /usr/doc by hand, but considering that many packages
already use doc-base to register HTML docs, I firmly believe that our time
would be *much* better spent if we concentrate, for example, on making
doc-base the standard procedure for registering docs, instead of making
the FHS transition a hell to everybody.

Thanks.

-- 
 "32215260b6abab7fffaf1f70ccf7cb1e" (a truly random sig)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Chris Waters <xtifr@dsp.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #192 received at 40706@bugs.debian.org (full text, mbox):

From: Chris Waters <xtifr@dsp.net>
To: 40706@bugs.debian.org
Subject: Re: Bug#40706: [AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: Mon, 19 Jul 1999 17:58:11 -0700
-----BEGIN PGP SIGNED MESSAGE-----

Manoj Srivastava <srivasta@debian.org> writes:

> PROPOSAL: Easing the transition from `/usr/doc' to `/usr/share/doc'
[...]
> During the transition, we need to provide backwards compatibility,
> firstly for programs ike `dwww', and `dhelp', and also for our users
> who have gotten used to looking under a single dir (`/usr/doc/') for
> docs (`/usr/doc/`package''). During the transition, the
> documentation could be in in two places, and that is not good

Programs like dwww and dhelp will already have to be modified to look
in both places, since users may have a mixture of old and new packages
installed even after we make the transition to policy 4.x.

Which leaves the "user is used to '/usr/doc'" objection, which is a
*purely* aesthetic objection, not a technical one.

> I understand that the forest of symlinks is ugly, but it is
> technically sound,

No, it is not.  It consumes unnecessary resources (inodes, directory
entries), and can cause severe problems if there are more than some
small number (five, I believe) of pending symlink lookups.  This is
not an area where the kernel is outstandingly robust.

Granted, the latter is unlikely to come up in practice, but it *is* a
genuine potential technical problem with this proposal.  And the
former is a very real issue, even an important one to some people.
This proposal may be more *aesthetically* pleasing than a
gradual-migration without symlinks, but it is NOT better in a
technical sense -- it is worse.

I know of *no* such technical problems with the simple migration,
package-by-package, with no symlinks involved, solution.

> I submit that aesthetics takes a back seat to functionality.

If so, then you should withdraw this proposal.

For now, I am formally objecting to this proposal.  I am not adamant;
I am open to debate.  I actually prefer the aesthetics of this
proposal, but it *is* technically inferior, and I am angry that it is
being promoted as technically superior.

I would *very* much like to see some other proposals on the table.
Personally, I would rather have dpkg (or maybe base-files?) be in
charge of placing the doc directories in the appropriate place at the
appropriate time.  I realize that there are *political* problems with
this idea, but I think it is both technically *and* aesthetically
superior to gradual migration, package-by-package, with or without
symlinks.  I think it is *very* possible to come up with a better
proposal which actually works.  But I'm not making one myself, as it
requires more effort than I want to spend at the moment.

So, if no better proposals come forth, and it becomes clear that
people *do* understand that this particular proposal *is* a
technically inferior one, but the general consensus is that the
aesthetics are more important, then I'll probably be willing to
withdraw my objection.  But not until then.

cheers
- -- 
Chris Waters   xtifr@dsp.net | I have a truly elegant proof of the
      or    xtifr@debian.org | above, but it is too long to fit into
http://www.dsp.net/xtifr     | this .signature file.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.5.1, an Emacs/PGP interface

iQCVAwUBN5PI1TZs0/7rwRsBAQG4HgQAnrltJZtnWFiuvzRSb3MXKfs+L1hJv/Tz
PIxpzhVaUicJAE09u9pdqr+r+1Em85XyztQppTMKIfc5Pl72x9u0dSJNv50UN4TO
6arflKfmhRyXGWEl2TgvHi/DUf0YAMCJQqf9BLUgRPSjCH5YCuml/bF4zkF3Ch0q
ZPIS33CiHD8=
=8q9I
-----END PGP SIGNATURE-----


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Nicolás Lichtmaier <nick@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #197 received at 40706@bugs.debian.org (full text, mbox):

From: Nicolás Lichtmaier <nick@debian.org>
To: 40706@bugs.debian.org
Subject: /usr/share/doc vs. /usr/doc transition
Date: Tue, 20 Jul 1999 01:19:57 -0300
 Ups.. I haven't read the constitution yet... =)

 May I second this proposal or I need a special hat? (I hope not a red one).



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #202 received at 40706@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: Santiago Vila <sanvila@unex.es>
Cc: 40706@bugs.debian.org
Subject: Re: Bug#40706: [AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: 19 Jul 1999 23:23:59 -0500
Hi,
>>"Santiago" == Santiago Vila <sanvila@unex.es> writes:

 Santiago> This is a high price to pay, very high.

        Adding a stanza to a couple of files too high a price to pay?
 
        Your solution ignores all the points made in the proposal:

        * The transition may take a long time, going by previous
          transitions, and not all packages are upgraded anywhere near
          simultaneously.

          I think that expecting _*all*_ packages to have moved before we
          release potato is futile, unless we do not plan on releasing
          potato for 18 months or so. We *_cannot_* expect to get FHS
          compliance in place by potato.

        * We should not break backwards compatibility during the transition
          period. This is a quality of implementation issue

          During the transition, we need to provide backwards
          compatibility, firstly for programs ike `dwww', and `dhelp', and
          also for our users who have gotten used to looking under a single
          dir (`/usr/doc/') for docs (`/usr/doc/`package''). During the
          transition, the documentation could be in in two places, and that
          is not good

        Against this, I do not think that this is too much to ask for.

        manoj
-- 
 Thank God a million billion times you live in Texas.
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


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #207 received at 40706@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: Santiago Vila <sanvila@unex.es>
Cc: 40706@bugs.debian.org
Subject: Re: Bug#40706: [AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: 19 Jul 1999 23:21:08 -0500
Hi,
>>"Santiago" == Santiago Vila <sanvila@unex.es> writes:

 Santiago> But your proposed solution creates an inmense lot of work
 Santiago> for everybody, just to keep compliance with a standard
 Santiago> (FSSTND) which is not the one that we should follow. Every

        You have a strange definition of immense.

        Secondly, we are not doing this for compliance with FSSTND,
 but for coherence and compatibility 


 Santiago> postinst has to be modified. Every postrm has to be
 Santiago> modified. Multi-binary packages will have to be modified a
 Santiago> lot, and in many cases maintainer scripts that never
 Santiago> existed before will have to be created as new and installed
 Santiago> by debian/rules.

        So? Greater changes than just that were needed to move my
 packages to FHS compliance in the first place. Every package
 does indeed have to be modified to do that.



 Santiago> This is a high price to pay, very high.

        I think you may well be in the minority here. 

 Santiago> We have a standard documentation format, which is
 Santiago> HTML. People is free of course to cd to /usr/doc by hand,
 Santiago> but considering that many packages already use doc-base to
 Santiago> register HTML docs, I firmly believe that our time would be
 Santiago> *much* better spent if we concentrate, for example, on
 Santiago> making doc-base the standard procedure for registering
 Santiago> docs, instead of making the FHS transition a hell to
 Santiago> everybody.

        Not all packages use HTML. ANd if you think that converting
 every package that does not use HTML to use HTML is easier than
 adding a stanza to a couple of scripts, you have a very skewed
 estimate. 

        Anyway, this is a non-sequitir. The user looking up the
 documentation manually needs be supported too.

        manoj
-- 
 Shaw to William Douglas Home: "Go on writing plays, my boy.  One of
 these days a London producer will go into his office and say to his
 secretary, `Is there a play from Shaw this morning?' and when she
 says `No,' he will say, `Well, then we'll have to start on the
 rubbish.' And that's your chance, my boy."
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


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #212 received at 40706@bugs.debian.org (full text, mbox):

From: Santiago Vila <sanvila@unex.es>
To: 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Tue, 20 Jul 1999 11:59:24 +0200 (CET)
Hi,

Being too much work is not the only point, the point is that this work
would be quite useless.

There will be users who will like the symlinks, but there will be also
users who will dislike them (have we thought of them too?).

If a user likes the symlinks, he/she may create by himself/herself
after upgrading to potato:

cd /usr/share/doc
for a in `ls`; do
  ln -s ../share/doc/$a /usr/doc/$a
done

This is a much more effective way to achieving the same goal (having
symlinks), but only people who dislike having docs in /usr/share/doc
would have to do it.

Thanks.

-- 
 "11a28113b6b4f762506df8a9375ab508" (a truly random sig)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Richard Braakman <dark@xs4all.nl>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #217 received at 40706@bugs.debian.org (full text, mbox):

From: Richard Braakman <dark@xs4all.nl>
To: Manoj Srivastava <srivasta@debian.org>, 40706@bugs.debian.org
Subject: Re: Bug#40706: [AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: Tue, 20 Jul 1999 11:02:00 +0200 (CEST)
Manoj Srivastava wrote:
> 3. Proposed solution
> --------------------
> 
>      I propose that there be a syymlink from /usr/doc/package =>
>      /usr/share/doc/package, managed by the package itself. Since there is
>      some concern that the packaging system does not deal well with
>      replacing a directory with a symbolic link, it is suggested that the
>      link be manipulated in the maintainer scripts postinst and postrm.

That should be postinst and prerm, to stay out of dpkg's way.  If you
remove it only in the postrm, then you will break downgrades to pre-FHS
versions.

To be completely correct, the symlink should also be removed in the
postrm if it is called with "disappear", because the prerm is not
called in that case.  It is rare for packages to disappear, however.

I think the symlink should be absolute, not relative.  /usr/doc is a
likely directory to be symlinked to somewhere else by the sysadmin
(for example, to deal with this transition :-), and the normal reason
for using relative links (that the link should still work if the
filesystem is mounted in an unusual place) is not very important here.

>           	  Postinst install:
>           if [ -d /usr/doc ]; then
>             if [ ! -e /usr/doc/$package ]; then
>               (cd /usr/doc;
>                if [ -d ../share/doc/$package ]; then
>                   ln -s ../share/doc/$package $package ;
>                fi
>               )
>             fi
>           fi

This seems unnecessarily complex.  You do not need to change the directory.
I suggest (using absolute links while I'm at it):

           if [ -d /usr/doc ]; then
             if [ ! -e /usr/doc/$package -a -d /usr/share/doc/$package ]; then
               ln -s /usr/share/doc/$package /usr/doc/$package
             fi
           fi

One problem remains: There is no $package variable available when the
maintainer scripts are run.  The package name will have to be hardcoded
in the scripts, and for multi-binary packages that will be rather more
work than is advertised.

Richard Braakman


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Kristoffer.Rose@ens-lyon.fr:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #222 received at 40706@bugs.debian.org (full text, mbox):

From: Kristoffer.Rose@ENS-Lyon.FR
To: srivasta@debian.org, 40706@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Bug#40706: [AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: Tue, 20 Jul 1999 18:18:45 +0200 (CEST)
Dear all,

Excuse me for asking a really silly question but I fear that we are
overlooking the obvious in our enthusiasm for the complicated.

I tried to do the following on one of my slink systems:

  # cd /usr/
  # ls share/doc
  ls: share/doc: No such file or directory
  # mv doc share/doc
  # ln -s share/doc doc

Thus no slink package on my system actually uses /usr/share/doc.  (If there
were I'd have done

  # cd /usr/
  # mv share/doc/* doc
  # mv doc share/doc
  # ln -s share/doc doc

instead; also remember to use a mv command that is safe across file
systems).  This merely puts a symlink in place:

  lrwxrwxrwx  root root  9 Jul 20 17:40 /usr/doc -> share/doc

which will ensure that all current and future documents will, in fact, be
stored in /usr/share/doc.  (I have used the same principle for /usr/src for
a while because I like my /usr partition to be read-only and I also like
recompiling kernels and stuff.)

All installations etc. will work as usual, in fact the simple test

  # test -d /usr/src && echo OK
  OK

demonstrates that the symbolic link *is* interpreted as a directory so
scripts etc. should work as usual.

ADVANTAGES:

Completely transparent to users, packages, etc.

Just one inode used.

Potato will be FHS-compliant except for the non-authorized single symbolic
link, and the upgrade path is trivial as shown above.

DANGERS:

A package P that creates BOTH /usr/doc/P and /usr/share/doc/P will be
broken.  I hope there are none...

A package that depends on /usr/doc not being a symlink will be broken.

A package that depends on the absolute path to somewhere being
/usr/doc/... will be broken.

SUMMARY:

We can impose this change with a very simple policy change:

1. REQUIRE that /usr/doc is a symlink to the FHS directory /usr/share/doc.

2. REQUEST that packages STORE their documentation in /usr/share/doc but
   explicitly make it "just" a normal bug to use /usr/doc. (Maybe say
   that later /usr/doc will be removed.) 

3. REQUIRE that packages ACCESS the documentation through /usr/share/doc
   and file critical bugs against the programs that do not respect that
   (such as dwww, dhelp, etc.).

4. File critical bugs against any package that evokes either of the three
   dangers.

So the only tricky question is this: where should the update happen?  I
suggest the postinst script of base-files.

Best,
	Kristoffer
-- 
Kristoffer Høgsbro Rose, phd, prof.associé  <http://www.ens-lyon.fr/~krisrose>
addr. LIP, Ecole Normale Supérieure de Lyon, 46 Allée d'Italie, F-69364 Lyon 7
phone +33(0)4 7272 8642, fax +33(0)4 7272 8080   <Kristoffer.Rose@ENS-Lyon.FR>
pgp f-p: A4D3 5BD7 3EC5 7CA2 924E D21D 126B B8E0   <krisrose@{debian,tug}.org>


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #227 received at 40706@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
To: Richard Braakman <dark@xs4all.nl>, 40706@bugs.debian.org
Cc: Manoj Srivastava <srivasta@debian.org>
Subject: Re: Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: Tue, 20 Jul 1999 12:47:52 -0400
Richard Braakman wrote:

> This seems unnecessarily complex.  You do not need to change the directory.
> I suggest (using absolute links while I'm at it):
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
>            if [ -d /usr/doc ]; then
>              if [ ! -e /usr/doc/$package -a -d /usr/share/doc/$package ]; the
> n
>                ln -s /usr/share/doc/$package /usr/doc/$package
>              fi
>            fi

Don't use absolute links.
From policy version 2.5.0.0:

4.5. Symbolic links
-------------------

     In general, symbolic links within a toplevel directory should be
     relative, and symbolic links pointing from one toplevel directory into
     another should be absolute. (A toplevel directory is a sub-directory
     of the root directory `/'.)

Peter


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #232 received at 40706@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: Kristoffer.Rose@ens-lyon.fr
Cc: 40706@bugs.debian.org, control@bugs.debian.org
Subject: Re: Bug#40706: [AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: 20 Jul 1999 12:55:59 -0500
Hi,
>>"Kristoffer" == Kristoffer Rose <Kristoffer.Rose@ens-lyon.fr> writes:

 Kristoffer> Excuse me for asking a really silly question but I fear
 Kristoffer> that we are overlooking the obvious in our enthusiasm for
 Kristoffer> the complicated.

        Enthusiam for the complicated? More like enthusiasm for
 correctness, or not rushing in  where angels fear to tread ...

         dpkg may well have problems with the symlink, so any
 packages still installing in /usr/doc/<package> could cause problems
 with dpkg. Since the move is likely to take a long time, this grand 
 move-in-one-fell-swoop is likely to be fraught with problems.

        manoj
-- 
 AmigaDOS Beer: The company has gone out of business, but their recipe
 has been picked up by some weird German company, so now this beer
 will be an import.  This beer never really sold very well because the
 original manufacturer didn't understand marketing. Like Unix Beer,
 AmigaDOS Beer fans are an extremely loyal and loud group. It
 originally came in a 16-oz. can, but now comes in 32-oz.  cans too.
 When this can was originally introduced, it appeared flashy and
 colorful, but the design hasn't changed much over the years, so it
 appears dated now.  Critics of this beer claim that it is only meant
 for watching TV anyway.
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


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #237 received at 40706@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: Richard Braakman <dark@xs4all.nl>
Cc: 40706@bugs.debian.org
Subject: Re: Bug#40706: [AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: 20 Jul 1999 12:47:53 -0500
Hi,
>>"Richard" == Richard Braakman <dark@xs4all.nl> writes:

 Richard> That should be postinst and prerm, to stay out of dpkg's
 Richard> way.  If you remove it only in the postrm, then you will
 Richard> break downgrades to pre-FHS versions.

        I shall so amend the proposal. 

 Richard> To be completely correct, the symlink should also be removed
 Richard> in the postrm if it is called with "disappear", because the
 Richard> prerm is not called in that case.  It is rare for packages
 Richard> to disappear, however.

        I shall add this paragraph too.

 Richard> I think the symlink should be absolute, not relative.
 Richard> /usr/doc is a likely directory to be symlinked to somewhere
 Richard> else by the sysadmin (for example, to deal with this
 Richard> transition :-), and the normal reason for using relative
 Richard> links (that the link should still work if the filesystem is
 Richard> mounted in an unusual place) is not very important here.

        Hmm. I am almost convinced. Opinions, folks?

 Richard> This seems unnecessarily complex.  You do not need to change
 Richard> the directory.

        Well, it makes me feel better when creating symbolic links. 
        
 Richard> One problem remains: There is no $package variable available
 Richard> when the maintainer scripts are run.  The package name will
 Richard> have to be hardcoded in the scripts, and for multi-binary
 Richard> packages that will be rather more work than is advertised.

        For multi binary packages I tend to have separate installation
 script for each binary package. Is that not the case generally? (I
 also tend to have the package name in a lot of maintainer scripts, as
 well as the version, but that does not seem to be the norm).

        Would something like this help?

PACKAGES="package_A package_B package_C"
for package in $PACKAGES; do
   if [ -d /usr/doc ]; then
     if [ ! -e /usr/doc/$package -a -d /usr/share/doc/$package ]; then
       ln -s /usr/share/doc/$package /usr/doc/$package
     fi
   fi
done

        manoj
-- 
 "Bureaucracy is a giant mechanism operated by pygmies." Honore de
 Balzac
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


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #242 received at 40706@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: Chris Waters <xtifr@dsp.net>
Cc: 40706@bugs.debian.org
Subject: Re: Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: 20 Jul 1999 15:16:16 -0500
Hi,
>>"Chris" == Chris Waters <xtifr@dsp.net> writes:

 Chris> Which leaves the "user is used to '/usr/doc'" objection, which is a
 Chris> *purely* aesthetic objection, not a technical one

        You are missing the point. It is not that users prefer one to
 the other, the objection is that there shall not be any one place for
 the users to look into.
.

 >> I understand that the forest of symlinks is ugly, but it is
 >> technically sound,

 Chris> No, it is not.  It consumes unnecessary resources (inodes,

        Most machines have less than a thousand packages installed. If
 less than 1k inodes are resaourse problem, then the machine is
 seriously swamped.

 Chris> directory entries), and can cause severe problems if there are
 Chris> more than some small number (five, I believe) of pending
 Chris> symlink lookups.  This is not an area where the kernel is
 Chris> outstandingly robust.

        Could you elaborate on this, please? Pending symlink lookups
 where? I tried running 6 processes just doing symlink lookups
 continuously, and nothing seems to be going wrong that I can see. 

 Chris> Granted, the latter is unlikely to come up in practice, but it
 Chris> *is* a genuine potential technical problem with this proposal.

        Can you point me to some documentation about this problem?

 Chris> And the former is a very real issue, even an important one to
 Chris> some people.  This proposal may be more *aesthetically*
 Chris> pleasing than a gradual-migration without symlinks, but it is
 Chris> NOT better in a technical sense -- it is worse.

        Depends on how hosed the kernel is wrt symlink lookups. 

 Chris> I know of *no* such technical problems with the simple migration,
 Chris> package-by-package, with no symlinks involved, solution.

        There is a quality of implementation issue involved.

 >> I submit that aesthetics takes a back seat to functionality.

 Chris> If so, then you should withdraw this proposal.

        No. Functionality is indeed enhanced by this proposal, though
 if the Linux kernel is fraginle in this regards, then we may have to
 rethink it.

 Chris> For now, I am formally objecting to this proposal.  I am not
 Chris> adamant; I am open to debate.

        That makes two objections.

 Chris> I actually prefer the aesthetics of this proposal, but it *is*
 Chris> technically inferior, and I am angry that it is being promoted
 Chris> as technically superior.

        Apart from the kernel problems, I do think it is technically
 superior. I must confess I was unaware of the pending symlink lookup
 issue. 

 Chris> I would *very* much like to see some other proposals on the table.
 Chris> Personally, I would rather have dpkg (or maybe base-files?) be in
 Chris> charge of placing the doc directories in the appropriate place at the
 Chris> appropriate time.

        I tend to be wary of grand change everything at once with all
 packages solutions. The upgrade granularity in Debian is the package,
 and I think it is imperative that we allow for partial upgrades and
 downgrades, and install a solution that recognizes that the upgrades
 to Debian happen a package at a time, and can take a long time to
 accomplish. 

 Chris> I realize that there are *political* problems with
 Chris> this idea, but I think it is both technically *and* aesthetically
 Chris> superior to gradual migration, package-by-package, with or without
 Chris> symlinks.

        I beg to differ. Espescially as dpkg has problems with
 symlinks being relaced by dirs. In general, changes that can be
 rolled back, are incremental, can be checkpointed, and can be
 incrementally rolled back are far to be preferred over a Boom! Bang!
 all at once change. And I am speaking technically, and from
 experience with large scale migrations.

 Chris> I think it is *very* possible to come up with a better
 Chris> proposal which actually works.  But I'm not making one myself,
 Chris> as it requires more effort than I want to spend at the moment.

        I see. I am sure if we sat and pondered over this for a decade
 or so, we couild indeed come up with a better solution.

 Chris> So, if no better proposals come forth, and it becomes clear that
 Chris> people *do* understand that this particular proposal *is* a
 Chris> technically inferior one, but the general consensus is that the
 Chris> aesthetics are more important, then I'll probably be willing to
 Chris> withdraw my objection.  But not until then.

        Very charged words. I do not agree that this is an technically
 inferior proposal (it may be unworklable, if the kernel is fubar'd,
 but a gradual change that allows for backwards compatibility, and
 allows the doc apckages time to change, is, IMHO, far from
 inferior. )

        manoj
-- 
 Dyslexia means never having to say that you're ysror.
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


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Julian Gilbey <J.D.Gilbey@qmw.ac.uk>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #247 received at 40706@bugs.debian.org (full text, mbox):

From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>
To: srivasta@debian.org (Manoj Srivastava)
Cc: 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: Tue, 20 Jul 1999 21:12:14 +0100 (BST)
Maybe I can suggest an alternative which will
 - not require packages to add anything to their maintainer scripts
 - not break the majority of packages, and
 - not create a forest of symlinks (which might be problematic, as has
   been pointed out)

The dpkg-buildpackage program (and maybe autobuilders as well?) could
be modified so that after the .deb is built, before anything is signed
or similar, something like the following is done (within any necessary
fakeroot environment, of course):

if dpkg -c ../$pva.deb | grep usr/doc/; then
cat >&2 <<EOF
I see that you are using the old FSSTND /usr/doc directory.
I will attempt to move /usr/doc to /usr/share/doc, but please
modify your package in order to make it FHS compliant.
EOF
  dpkg -x ../$pva.deb ${TMPDIR-/tmp}/$pva
  dpkg -e ../$pva.deb ${TMPDIR-/tmp}/$pva/DEBIAN
  mv ${TMPDIR-/tmp}/$pva/usr/doc ${TMPDIR-/tmp}/$pva/usr/share/doc
  dpkg --build ${TMPDIR-/tmp}/$pva ..
fi

This would therefore only require one package to be upgraded in order
to handle most packages (even if it is dpkg!), and autobuilders could
recompile most packages automatically.

This would fail if any of the following happen:
 - the package contained any symlinks (relative or absolute) to
   /usr/doc, although the package would still build in such a case
 - the maintainer scripts made assumptions about /usr/doc existing;
   this will hopefully not affect too many packages.

Using this, I could feasibly see all packages becoming /usr/share/doc
using by the time potato is released, as the individual packages won't
directly need modification in order to make them FHS compliant.

   Julian

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
        Debian GNU/Linux Developer,  see http://www.debian.org/~jdg


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #252 received at 40706@bugs.debian.org (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: 40706@bugs.debian.org
Subject: Re: Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: Tue, 20 Jul 1999 02:41:26 +0200
Hi,

On Mon, Jul 19, 1999 at 11:23:59PM -0500, Manoj Srivastava wrote:
> >>"Santiago" == Santiago Vila <sanvila@unex.es> writes:
> 
>  Santiago> This is a high price to pay, very high.
> 
>         Adding a stanza to a couple of files too high a price to pay?

The price is actually higher. Richard already pointed out some corrections
to your proposal, which add complication.

But the real expense is elsewhere. I wonder why this hasn't come up before,
but here it is:

1. A lot of packages currently need no postinst or prerm(postrm, depends if
you use Manojs proposal or Richards correction) script currently, and we
would need to add one _only_ for this transition.

2. The prerm/postrm script must never go again, because we handle smooth
upgrades even if you jump a version number. Otherwise, you will end up with
a crufty symlink.

So, the price is:

a. A lot of work to add some stanzas to two scripts, probably creating these
scripts if they don't exist.

b. A few hundreds additional install scripts, one or two for each package
that exists for the transition period and up to one for each package
afterwards. Of course, _new_ packages after the transition period don't need
those script snippets.

Let's calculate some numbers:

ulysses:~# ls /var/lib/dpkg/info/*.list|wc
    655     655   22488
ulysses:~# ls /var/lib/dpkg/info/*.postinst|wc
    446     446   17518
ulysses:~# ls /var/lib/dpkg/info/*.prerm|wc
    169     169    6139
ulysses:~# ls /var/lib/dpkg/info/*.postrm|wc
    231     231    8336

Let's extrapolate the numbers for the whole Debian archive
(main+contrib+non-free), ~3000 packages.

That means, ~1000 new postinst scripts that were not necessary before in the
transition period.

~2000 new prerm/postrm scripts that must never go, even after the
transition period.

Personally, I think this is overkill for this particular problem. There
exists little system interfaces that make use of /usr/doc (dwww and dhelp
are notable exceptions). "Get real", I mean, it's cool that we have such a
cool packaging system that allows such smooth upgrades, but I think we
should concentrate on more important issues. Also, we should pay a bit
attention to the ressources. Adding those symlinks will use up ~600 more
inodes (if you have a 1GB system like me) and (200+400)*4kb = 2.4 MB more
disk space in /var/lib/dpkg/info/.

A little script that creates symlinks in /usr/doc for each directory in
/usr/share/doc was already posted, we could advertise it to our users who
really want that.

The above calculation tells me that the cost is higher than the benefit.
Hence, I formaly object to this proposal.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann              GNU    http://www.gnu.org     master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Richard Braakman <dark@xs4all.nl>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #257 received at 40706@bugs.debian.org (full text, mbox):

From: Richard Braakman <dark@xs4all.nl>
To: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
Cc: 40706@bugs.debian.org, srivasta@debian.org
Subject: Re: Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: Wed, 21 Jul 1999 02:58:52 +0200 (CEST)
Peter S Galbraith wrote:
> Don't use absolute links.
> >From policy version 2.5.0.0:
> 
> 4.5. Symbolic links
> -------------------
> 
>      In general, symbolic links within a toplevel directory should be
>      relative, and symbolic links pointing from one toplevel directory into
>      another should be absolute. (A toplevel directory is a sub-directory
>      of the root directory `/'.)

You forgot to quote the rationale :)  I think this should be an exception,
for the reasons I've given.  Since we're amending policy, we can easily
specify an exception to this general rule.

Richard


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Richard Braakman <dark@xs4all.nl>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #262 received at 40706@bugs.debian.org (full text, mbox):

From: Richard Braakman <dark@xs4all.nl>
To: Manoj Srivastava <srivasta@debian.org>
Cc: Richard Braakman <dark@xs4all.nl>, 40706@bugs.debian.org
Subject: Re: Bug#40706: [AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: Wed, 21 Jul 1999 03:13:55 +0200 (CEST)
Manoj Srivastava wrote:
>  Richard> This seems unnecessarily complex.  You do not need to change
>  Richard> the directory.
> 
>         Well, it makes me feel better when creating symbolic links. 

Okay, a matter of taste :) I find it hard to read scripts that change
directories, and I also think it encourages the wrong way of thinking
about "ln -s" (which is unlike any other file operation when it takes
its first argument absolutely literally.)

>  Richard> One problem remains: There is no $package variable available
>  Richard> when the maintainer scripts are run.  The package name will
>  Richard> have to be hardcoded in the scripts, and for multi-binary
>  Richard> packages that will be rather more work than is advertised.
> 
>         For multi binary packages I tend to have separate installation
>  script for each binary package. Is that not the case generally? (I
>  also tend to have the package name in a lot of maintainer scripts, as
>  well as the version, but that does not seem to be the norm).

I do not know.  I thought the xserver-* scripts were like that (a
common script for many packages), but they seem to have the package
name in each script.

It would annoy me to have to add parameter substitution just for this,
but I guess that is also a matter of aesthetics.

>         Would something like this help?
> 
> PACKAGES="package_A package_B package_C"
> for package in $PACKAGES; do
>    if [ -d /usr/doc ]; then
>      if [ ! -e /usr/doc/$package -a -d /usr/share/doc/$package ]; then
>        ln -s /usr/share/doc/$package /usr/doc/$package
>      fi
>    fi
> done

I don't think so; each package must take care of its own link, to avoid
getting in dpkg's way.  Examples of this going wrong are pretty complex
for the postinst, but for the prerm it's easy: each package must remove
only its own link.

Richard Braakman


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Steve Greenland <stevegr@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #267 received at 40706@bugs.debian.org (full text, mbox):

From: Steve Greenland <stevegr@debian.org>
To: 40706@bugs.debian.org
Subject: Re: Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: Tue, 20 Jul 1999 22:33:11 -0500
On 19-Jul-99, 19:41 (CDT), Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> wrote: 
> 
> The price is actually higher. Richard already pointed out some corrections
> to your proposal, which add complication.
> 
> But the real expense is elsewhere. I wonder why this hasn't come up before,
> but here it is:
> 
> 1. A lot of packages currently need no postinst or prerm(postrm, depends if
> you use Manojs proposal or Richards correction) script currently, and we
> would need to add one _only_ for this transition.
> 
> 2. The prerm/postrm script must never go again, because we handle smooth
> upgrades even if you jump a version number. Otherwise, you will end up with
> a crufty symlink.

I think I agree with this, the effort and additional cruft is to big
for the benefit. As somebody who never use dwww or dhelp, but is always
ls'ing through /usr/doc by hand, I think I'd rather spend the two
minutes writing a script that looks in both /usr/doc and /usr/share
doc than force every package to have a postinst and prerm. And while
the individual effort to add the required lines is low, the cumulative
effort is not.

And it seems to me a that a script that maintained
/usr/doc/whatever->/usr/share/doc/whatever links is pretty trivial (did
I just volunteer to write it?).

Steve


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to ron@microtronics.com.au (Ron):
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #272 received at 40706@bugs.debian.org (full text, mbox):

From: ron@microtronics.com.au (Ron)
To: Manoj Srivastava <srivasta@debian.org>, 40706@bugs.debian.org
Subject: Re: Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: Wed, 21 Jul 1999 15:11:20 +0930 (CST)
Hi,

>  Richard> I think the symlink should be absolute, not relative.
>  Richard> /usr/doc is a likely directory to be symlinked to somewhere
>  Richard> else by the sysadmin (for example, to deal with this
>  Richard> transition :-), and the normal reason for using relative
>  Richard> links (that the link should still work if the filesystem is
>  Richard> mounted in an unusual place) is not very important here.
> 
>         Hmm. I am almost convinced. Opinions, folks?

As one of the people likely to do this (ie. symlink /usr/doc to
/usr/share/doc/this_used_to_be_usr_doc) it would seem to me that absolute
symlinks would be a little more robust in this case.


Also has anybody considered that sysadmins who do desire to have symlinks
in /usr/doc to the package dirs in /usr/share could create them for
themselves with lndir(1x) or some similar tool..  (yes I know this greatly
lacks the polish of some other solutions offered, but there seems to be some
division still over the desirability of us creating such a symlink farm
by default.. ??)   

best,
Ron.


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Decklin Foster <decklin@home.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #277 received at 40706@bugs.debian.org (full text, mbox):

From: Decklin Foster <decklin@home.com>
To: 40706@bugs.debian.org
Subject: Re: Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: Wed, 21 Jul 1999 09:51:10 -0400
Manoj Srivastava writes:

> dpkg may well have problems with the symlink, so any packages still
> installing in /usr/doc/<package> could cause problems with dpkg.
> Since the move is likely to take a long time, this grand
> move-in-one-fell-swoop is likely to be fraught with problems.

This is a weak argument. If dpkg is broken, dpkg should be fixed. I
submit that it fould be best to freeze, *then* fix dpkg, then simply
symlink /usr/doc to /usr/share/doc.

Unfortunately my application has not been processed, so I cannot
formally object to this proposal.

-- 
Debian GNU/Linux - http://www.debian.org/
The Web is to graphic design as the fax machine is to literature.


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #282 received at 40706@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>
Cc: 40706@bugs.debian.org
Subject: Re: Bug#40706: usr/share/doc vs. /usr/doc
Date: 21 Jul 1999 09:53:52 -0500
Hi,
>>"Julian" == Julian Gilbey <J.D.Gilbey@qmw.ac.uk> writes:

 Julian> Maybe I can suggest an alternative which will
 Julian>  - not require packages to add anything to their maintainer scripts
 Julian>  - not break the majority of packages, and
 Julian>  - not create a forest of symlinks (which might be problematic, as has
 Julian>    been pointed out)

        Please break this out as a separate proposal, this definitely
 has potential, and should not be lost in the clutter.

        manoj
-- 
 When it comes to broken marriages most husbands will split the blame
 -- half his wife's fault, and half her mother's.
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


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #287 received at 40706@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: Steve Greenland <stevegr@debian.org>
Cc: 40706@bugs.debian.org
Subject: Re: Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: 21 Jul 1999 10:40:18 -0500
Hi,
>>"Steve" == Steve Greenland <stevegr@debian.org> writes:


 Steve> I think I agree with this, the effort and additional cruft is to big
 Steve> for the benefit. 

        Do you formally object to the proposal?

 Steve> And it seems to me a that a script that maintained
 Steve> /usr/doc/whatever->/usr/share/doc/whatever links is pretty trivial (did
 Steve> I just volunteer to write it?).

        This should be a separate proposal, as I have pointed out in
 another message.

        manoj
-- 
 You love your home and want it to be beautiful.
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


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Gordon Matzigkeit <gord@fig.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #292 received at 40706@bugs.debian.org (full text, mbox):

From: Gordon Matzigkeit <gord@fig.org>
To: 40706@bugs.debian.org
Subject: Reasons for not moving at all
Date: 21 Jul 1999 11:03:26 -0600
Marcus's argument here is most compelling.  It is not the present cost
of Manoj's proposal that is prohibitive, it is the future cost of all
those prerm scripts.  And so, I formally object to this proposal.

However, Manoj's arguments against other ways of moving to
/usr/share/doc still hold: any one-shot change will likely end up
breaking compatibility.

So, I am now convinced that not moving at all is the only sane thing
we can do.  Let's focus our energies on working on actual potato bugs
rather than trying to appease the evil FHS gods.

I think all I can say is that it may have been a terrible idea for
people to start using /usr/doc in the first place, but it definitely
is a worse idea now for the FHS to move this directory to
/usr/share/doc.  What is the rationale for this change, when all
distributions already use /usr/doc?

Can somebody remind me again why it's so important to be FHS-compliant
on this issue?  Why not just change the few /usr/share/doc packages
back to /usr/doc,

 ln -s /usr/doc /usr/share/doc  # FHS compatibility

and be done with it?

-- 
 Gordon Matzigkeit <gord@fig.org>  //\ I'm a FIG (http://www.fig.org/)
Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Chris Waters <xtifr@dsp.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #297 received at 40706@bugs.debian.org (full text, mbox):

From: Chris Waters <xtifr@dsp.net>
To: 40706@bugs.debian.org
Subject: Re: Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: 21 Jul 1999 11:43:50 -0700
Manoj Srivastava <srivasta@debian.org> writes:

> >>"Chris" == Chris Waters <xtifr@dsp.net> writes:

>  Chris> Which leaves the "user is used to '/usr/doc'" objection, which is a
>  Chris> *purely* aesthetic objection, not a technical one

>         You are missing the point. It is not that users prefer one to
>  the other, the objection is that there shall not be any one place for
>  the users to look into.

I wasn't the one who said the bit in quotes, you were.  Ok, you've now
raised a new point, and I agree with you that it's a much better
point, but it's *still* an aesthetic consideration!  The information
is just as available if we use two locations.  There is nothing
*technically* wrong with using two locations; it's functionally
equivalent, it's merely somewhat uglier.

And in any case, it's not one location vs. two.  It's more like three
or four vs. four or five.  We have man pages, info files, built-in
help systems, dwww and dhelp, oddballs like gnome-help, and, finally,
as a point of last resort (at least for non-masochists), we have the
all-too-often useless /usr/doc area.

>  >> I understand that the forest of symlinks is ugly, but it is
>  >> technically sound,

>  Chris> No, it is not.  It consumes unnecessary resources (inodes,

>         Most machines have less than a thousand packages installed.

I didn't say that was a *strong* technical flaw.  I merely said that
it was a technical flaw.  Objecting that it's a minor flaw doesn't
make it not a flaw.  So far, you haven't presented a SINGLE technical
argument in favor of this proposal!

[more than five pending symlinks and the linux kernel]

>         Could you elaborate on this, please? Pending symlink lookups
>  where?

First of all, I should make it clear that in practice, this is
probably even *less* important than the previous technical objection.
But it is, still, a *technical* problem, however minor.

The limitation can be found in fs/ext2/symlink.c, in the function
ext2_follow_link(), where it says:

        if (current->link_count > 5) {
                iput (dir);
                iput (inode);
                return -ELOOP;
        }

(Nice, eh?  Not even a symbolic constant, just a hard-coded `5'.)

I'm a little fuzzy on how this is triggered, though.  I know it's
*not* triggered by a simple chain of symlinks, like:

   a -> b, b -> c, c -> d, d -> e, e -> f, f -> g, g -> h

I *believe* that a pending symlink happens when the inode of what a
link points to cannot be found without resolving another symlink
first.  In the case above, the inode of `b' can be found right away --
it's a symlink, but its inode can be found, so `a' doesn't pend.
However, in a case like:

  a -> b/c, b -> d/e

the inode of what `a' points to (`c') cannot be found until the
symlink `b' is resolved.  So `a' pends on `b'.

I *believe* that's how it works, but for the actual details, well,
UTSL.  :-)

>         There is a quality of implementation issue involved.

There is an *aesthetic* quality of implementation issue involved,
yes.  Both of the technical objections I raised are *very* minor.
They are, however, technical objections.

>  >> I submit that aesthetics takes a back seat to functionality.

>  Chris> If so, then you should withdraw this proposal.

>         No. Functionality is indeed enhanced by this proposal, though

How so?  I see no additional functionality provided by these links.
The user still has to check several possible locations for
documentation (man pages, info files, etc.).  And even so, the user
*can* still find the information, whether we have one location or six.
That's not additional functionality, it's simply easier and more
elegant.  Functionally, it's IDENTICAL!

Again, I say, IF you ACTUALLY believe that aesthetics takes a back
seat, then you should withdraw this proposal.  Personally, I disagree
with you; I think aesthetics can be more important in some cases.  I'm
just not sure whether this is such a case or not.

>         Apart from the kernel problems, I do think it is technically
>  superior. I must confess I was unaware of the pending symlink lookup
>  issue. 

Please offer one single, solitary *technical* reason for the proposal.
You have not provided *any* yet.  It's a very pleasing proposal
aesthetically (although it would be more so if it weren't for man
pages, info files, etc.).  But not one bit technically superior that I
can see.  Either you're hiding something, or you have a very different
definition of "technical" than I do.

>  Chris> I think it is *very* possible to come up with a better
>  Chris> proposal which actually works.  But I'm not making one myself,
>  Chris> as it requires more effort than I want to spend at the moment.

>         I see. I am sure if we sat and pondered over this for a decade
>  or so, we couild indeed come up with a better solution.

So?  We do have a default plan we can pursue in the meantime.  We have
people uploading packages that use /usr/share/doc only, and the
universe hasn't collapsed.  There's nothing *technically* wrong with
our default plan; it's merely a question of aesthetics.  So I have no
problem sticking with the default for now and waiting to see if a
truly better plan *does* come along.

The problem I have is that you're presenting this plan which has some
very minor technical flaws, and a great deal of aesthetic appeal, and
then arguing that we should ignore aesthetics.

I don't want to be an ass, so, if everyone agrees that aesthetics are
more important in this case, I'll withdraw my objection.  Or, if you
come up with a solid technical reason to prefer this plan -- one that
doesn't merely involve dubious arguments about "ease of use" -- I'll
withdraw.  So far, I've seen neither.

cheers
-- 
Chris Waters   xtifr@dsp.net | I have a truly elegant proof of the
      or    xtifr@debian.org | above, but it is too long to fit into
http://www.dsp.net/xtifr     | this .signature file.


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joey@kitenet.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #302 received at 40706@bugs.debian.org (full text, mbox):

From: Joey Hess <joey@kitenet.net>
To: Chris Waters <xtifr@dsp.net>, 40706@bugs.debian.org
Subject: Re: Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: Wed, 21 Jul 1999 11:48:14 -0700
Chris Waters wrote:
> Programs like dwww and dhelp will already have to be modified to look
> in both places, since users may have a mixture of old and new packages
> installed even after we make the transition to policy 4.x.
> 
> Which leaves the "user is used to '/usr/doc'" objection, which is a
> *purely* aesthetic objection, not a technical one.

No, as has been said many, MANY times before, the problem is one of
incremental upgrades. I will not describe the problem here again because I'm
quite sick of repeating myself; read any of my past postings on the subject.

-- 
see shy jo


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joey@kitenet.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #307 received at 40706@bugs.debian.org (full text, mbox):

From: Joey Hess <joey@kitenet.net>
To: Manoj Srivastava <srivasta@debian.org>, 40706@bugs.debian.org
Cc: Kristoffer.Rose@ens-lyon.fr, debian-policy@lists.debian.org
Subject: Re: Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: Wed, 21 Jul 1999 12:17:29 -0700
Manoj Srivastava wrote:
>          dpkg may well have problems with the symlink, so any
>  packages still installing in /usr/doc/<package> could cause problems
>  with dpkg. Since the move is likely to take a long time, this grand 
>  move-in-one-fell-swoop is likely to be fraught with problems.

After reading Kristoffer's post I am wondering if we're being too paranoid.
I know dpkg works ok if the sysadmin locally moves something and symlinks it
similarly to how he proposes. At least, the only reports of failures when
that is done that I've seen were all in xaw-wrappers where I was too zealous
in following symlinks. I don't remember any dpkg problems related to it.

I'm sure dpkg would get very upset if it thought there were files in both
/usr/doc/ and /usr/share/doc and the files had the same name and the
directories were linked, but as Kristoffer points out, policy can just
forbid this.

How much testing would we need to give this method before you'd be content
to use it?

-- 
see shy jo


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Philip Hands <phil@hands.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #312 received at 40706@bugs.debian.org (full text, mbox):

From: Philip Hands <phil@hands.com>
To: Gordon Matzigkeit <gord@fig.org>
Cc: 40706@bugs.debian.org
Subject: Re: Bug#40706: Reasons for not moving at all
Date: 21 Jul 1999 23:54:41 +0100
Gordon Matzigkeit <gord@fig.org> writes:

> Can somebody remind me again why it's so important to be FHS-compliant
> on this issue?  Why not just change the few /usr/share/doc packages
> back to /usr/doc,

Because people who want to save disk space by mounting architecture
independant directories from a common NFS server, say, really need to
have all the architecture independant bits under one subdirectory.

How one goes about upgrading all these heterogeneous machines on a
network is another issue, which may be solved at some point.

Cheers, Phil.


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #317 received at 40706@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: Chris Waters <xtifr@dsp.net>
Cc: 40706@bugs.debian.org
Subject: Re: Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: 21 Jul 1999 23:27:14 -0500
Hi,
>>"Chris" == Chris Waters <xtifr@dsp.net> writes:

 Chris> Manoj Srivastava <srivasta@debian.org> writes:
 >> >>"Chris" == Chris Waters <xtifr@dsp.net> writes:

 Chris> Which leaves the "user is used to '/usr/doc'" objection, which is a
 Chris> *purely* aesthetic objection, not a technical one

 >> You are missing the point. It is not that users prefer one to
 >> the other, the objection is that there shall not be any one place for
 >> the users to look into.

 Chris> I wasn't the one who said the bit in quotes, you were.  Ok,
 Chris> you've now raised a new point, and I agree with you that it's
 Chris> a much better point, but it's *still* an aesthetic
 Chris> consideration!  The information is just as available if we use
 Chris> two locations.  There is nothing *technically* wrong with
 Chris> using two locations; it's functionally equivalent, it's merely
 Chris> somewhat uglier.


        The fact that a single probe into the location derived using
 the pacjage name is no longe guaranteed to work is indeed a technical
 fault. Mreley repeating that it is not so does not make it
 non-technical. 

 Chris> And in any case, it's not one location vs. two.  It's more
 Chris> like three or four vs. four or five.  We have man pages, info
 Chris> files, built-in help systems, dwww and dhelp, oddballs like
 Chris> gnome-help, and, finally, as a point of last resort (at least
 Chris> for non-masochists), we have the all-too-often useless
 Chris> /usr/doc area.

        The only one in consideration here is the /usr/doc area. 

 >> >> I understand that the forest of symlinks is ugly, but it is
 >> >> technically sound,

 Chris> No, it is not.  It consumes unnecessary resources (inodes,

 >> Most machines have less than a thousand packages installed.

 Chris> I didn't say that was a *strong* technical flaw.  I merely

        It is not, IMHO, a flaw. The Debian installation requires hard
 drive space is a requirement, not a flaw. Same here. 

 Chris> said that it was a technical flaw.  Objecting that it's a
 Chris> minor flaw doesn't make it not a flaw.

        Calling a requirement a flaw does not make it a flaw either.

 Chris> So far, you haven't presented a SINGLE technical argument in
 Chris> favor of this proposal!

        I am afraid that you are not reading my posts then. Read the
 proposal; the specs for the transition were postred there. 

 Chris> [more than five pending symlinks and the linux kernel]

 >> Could you elaborate on this, please? Pending symlink lookups
 >> where?

 Chris> First of all, I should make it clear that in practice, this is
 Chris> probably even *less* important than the previous technical objection.
 Chris> But it is, still, a *technical* problem, however minor.

 Chris> I'm a little fuzzy on how this is triggered, though.  I know it's
 Chris> *not* triggered by a simple chain of symlinks, like:

        Cool. However, as you say, in practical terms, this is
 irrelevant. This is not a debating society. We are trying to
 seekl real world answers, and I think we can accept the risk
 of this exceeding bizzarre bug ever happening.

 >> There is a quality of implementation issue involved.

 Chris> There is an *aesthetic* quality of implementation issue involved,
 Chris> yes.  Both of the technical objections I raised are *very* minor.
 Chris> They are, however, technical objections.
        
        As I said, they are ignorable, for all the real world impact
 they are likely to have. 

 Chris> How so?  I see no additional functionality provided by these links.
 Chris> The user still has to check several possible locations for
 Chris> documentation (man pages, info files, etc.).  And even so, the user
 Chris> *can* still find the information, whether we have one location or six.
 Chris> That's not additional functionality, it's simply easier and more
 Chris> elegant.  Functionally, it's IDENTICAL!

        In other words, since the information is not all in one place,
 adding yet another location is all right. I think not.

 Chris> Again, I say, IF you ACTUALLY believe that aesthetics takes a
 Chris> back seat, then you should withdraw this proposal.
 Chris> Personally, I disagree with you; I think aesthetics can be
 Chris> more important in some cases.  I'm just not sure whether this
 Chris> is such a case or not.

        I still think that looking for the examples and copyright file
 are enough to justify a one stop solution. Moving information and
 having two different locations for this specific type of
 insformation, which was under one dir, and shall be so again,
 providing no such location in the transition is a technical flaw.

        

 >> Apart from the kernel problems, I do think it is technically
 >> superior. I must confess I was unaware of the pending symlink lookup
 >> issue. 

 Chris> Please offer one single, solitary *technical* reason for the proposal.
 Chris> You have not provided *any* yet.  It's a very pleasing

        I think I have. Please read the archives. Several peolpe are
 of the opinion that having two different places to look for this
 information is irritating enough to marr the distribution, and this
 additional lookup not being avoided is indeed a technical oversight.


 >> I see. I am sure if we sat and pondered over this for a decade
 >> or so, we couild indeed come up with a better solution.

 Chris> So?  We do have a default plan we can pursue in the meantime.
 Chris> We have people uploading packages that use /usr/share/doc
 Chris> only, and the universe hasn't collapsed.  There's nothing

        So the only flaws we fix are the finalk grand collapse? This
 is very silly. 

 Chris> *technically* wrong with our default plan; it's merely a

        Bullshit.

        manoj
-- 
 I owe the public nothing. J.P. Morgan
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


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #322 received at 40706@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: Gordon Matzigkeit <gord@fig.org>
Cc: 40706@bugs.debian.org, control@bugs.debian.org
Subject: Re: Bug#40706: Reasons for not moving at all
Date: 21 Jul 1999 23:33:52 -0500
retitle 40706 [REJECTED 21/7/99] /usr/share/doc vs. /usr/doc transition
severity 40706 fixed
thanks

Hi,
>>"Gord" == Gordon Matzigkeit <gord@fig.org> writes:

 Gord> Marcus's argument here is most compelling.  It is not the
 Gord> present cost of Manoj's proposal that is prohibitive, it is the
 Gord> future cost of all those prerm scripts.  And so, I formally
 Gord> object to this proposal.

        Bang!! That was the 4rth formal objection, and thus this
 proposal dies. It can be revived as a general resolution, but I do
 not have the enrgy to do that. We now have no amendment on the table
 to move the /usr/doc directories in a consistent fashion.


 Gord> However, Manoj's arguments against other ways of moving to
 Gord> /usr/share/doc still hold: any one-shot change will likely end up
 Gord> breaking compatibility.

 Gord> So, I am now convinced that not moving at all is the only sane thing
 Gord> we can do.  Let's focus our energies on working on actual potato bugs
 Gord> rather than trying to appease the evil FHS gods.

        We have already decided to accept the FHS. Please bring this
 as a separate proposal, that we not fully comply with the FHS. I
 suspect that you shall need a general resolution to carry that
 through.

 Gord> I think all I can say is that it may have been a terrible idea for
 Gord> people to start using /usr/doc in the first place, but it definitely
 Gord> is a worse idea now for the FHS to move this directory to
 Gord> /usr/share/doc.  What is the rationale for this change, when all
 Gord> distributions already use /usr/doc?

        Please ask this in the FHS discussion lists.

 Gord> Can somebody remind me again why it's so important to be FHS-compliant
 Gord> on this issue?  Why not just change the few /usr/share/doc packages
 Gord> back to /usr/doc,

        Because this is policy. 

        manoj

-- 
 It is enough to make one sympathize with a tyrant for the
 determination of his courtiers to deceive him for their own personal
 ends... Russell Baker and Charles Peters
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


Changed bug title. Request was from Manoj Srivastava <srivasta@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `fixed'. Request was from Manoj Srivastava <srivasta@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Anthony Towns <aj@azure.humbug.org.au>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #331 received at 40706@bugs.debian.org (full text, mbox):

From: Anthony Towns <aj@azure.humbug.org.au>
To: Manoj Srivastava <srivasta@debian.org>, 40706@bugs.debian.org
Cc: Gordon Matzigkeit <gord@fig.org>
Subject: Re: Bug#40706: Reasons for not moving at all
Date: Thu, 22 Jul 1999 16:08:26 +1000
[Message part 1 (text/plain, inline)]
On Wed, Jul 21, 1999 at 11:33:52PM -0500, Manoj Srivastava wrote:
>         Bang!! That was the 4rth formal objection, and thus this
>  proposal dies. It can be revived as a general resolution, but I do
>  not have the enrgy to do that. We now have no amendment on the table
>  to move the /usr/doc directories in a consistent fashion.

Perhaps someone would like to upload a .deb that does nothing more than
maintain symlinks?

Something as simple as having a /etc/cron.daily script that does:

	[ -d /usr/doc ] || exit 0

	cd /usr/share/doc
	for dir in *; do
		[ -e "/usr/doc/$a" ] || ln -s /usr/share/doc/$a /usr/doc/$a
	done
	
seems to me like an acceptable solution at this point.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.

       ``There's nothing worse than people with a clue.
             They're always disagreeing with you.'' 
                                 -- Andrew Over
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Michael Stone <mstone@itri.loyola.edu>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #336 received at 40706@bugs.debian.org (full text, mbox):

From: Michael Stone <mstone@itri.loyola.edu>
To: Anthony Towns <aj@azure.humbug.org.au>, 40706@bugs.debian.org
Subject: Re: Bug#40706: Reasons for not moving at all
Date: Thu, 22 Jul 1999 07:57:31 -0400
On Thu, Jul 22, 1999 at 04:08:26PM +1000, you wrote:
> Perhaps someone would like to upload a .deb that does nothing more than
> maintain symlinks?
> 
> Something as simple as having a /etc/cron.daily script that does:
> 
> 	[ -d /usr/doc ] || exit 0
> 
> 	cd /usr/share/doc
> 	for dir in *; do
> 		[ -e "/usr/doc/$a" ] || ln -s /usr/share/doc/$a /usr/doc/$a
> 	done
> 	
> seems to me like an acceptable solution at this point.

Uh huh. And who handles the dangling symlinks you leave when a package
gets uninstalled?

Mike Stone



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Anthony Towns <aj@azure.humbug.org.au>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #341 received at 40706@bugs.debian.org (full text, mbox):

From: Anthony Towns <aj@azure.humbug.org.au>
To: Michael Stone <mstone@itri.loyola.edu>
Cc: 40706@bugs.debian.org
Subject: Re: Bug#40706: Reasons for not moving at all
Date: Thu, 22 Jul 1999 22:13:32 +1000
On Thu, Jul 22, 1999 at 07:57:31AM -0400, Michael Stone wrote:
> On Thu, Jul 22, 1999 at 04:08:26PM +1000, you wrote:
> > Perhaps someone would like to upload a .deb that does nothing more than
> > maintain symlinks?
> > Something as simple as having a /etc/cron.daily script that does:
> > 	[ -d /usr/doc ] || exit 0
> > 	cd /usr/share/doc
> > 	for dir in *; do
> > 		[ -e "/usr/doc/$a" ] || ln -s /usr/share/doc/$a /usr/doc/$a
> > 	done
> > seems to me like an acceptable solution at this point.
> Uh huh. And who handles the dangling symlinks you leave when a package
> gets uninstalled?

And, gosh darn it, who'd put in the "#!" line at the top?

You might also want to do something more careful than using "*", and
you probably want to use "$dir" instead of "$a".

Whatever.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.

       ``There's nothing worse than people with a clue.
             They're always disagreeing with you.'' 
                                 -- Andrew Over


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Nicolás Lichtmaier <nick@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #346 received at 40706@bugs.debian.org (full text, mbox):

From: Nicolás Lichtmaier <nick@debian.org>
To: 40706@bugs.debian.org
Subject: Supporting users.
Date: Fri, 23 Jul 1999 03:47:14 -0300
 You don't care about the user. It seems that you just like to have your
distribution meeting many TLA standards and being the right distribution for
YOU. 

 The objections to this proposal were all to silly, too small.. too (arg! I
can't find a word... too.. picky?).

 Is it about the potential couple of hundreds of kbs of prerm scripts that
bothers you...? You seem to care now about optimizing every bit of speed
or space and not technical excelence. Look dpkg and its Packages file... is
it designed for speed? No.. but is robust and easily manageable by common
tools...

 I use Debian at work, and many of my coworkers do or use the machine I
administer. I know that this will be annoying to them. It will be annoying
to tell them that they no longer will be able to use dhelp or dwww, or to
support them when they don't find /usr/doc/package...

 I also know that this is far to be a major issue, but what I cannot stand
here is the inexistance of technical arguments.. or.. the wrong valuation
(?) of the arguments...

 Well... the issue is closed.. isn't it?

 (Sorry for my lousy (?) English.. he =) ) Bye!


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Chris Waters <xtifr@dsp.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #351 received at 40706@bugs.debian.org (full text, mbox):

From: Chris Waters <xtifr@dsp.net>
To: 40706@bugs.debian.org
Subject: Re: Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: 23 Jul 1999 08:51:44 -0700
Manoj Srivastava <srivasta@debian.org> writes:

>         The fact that a single probe into the location derived using
>  the pacjage name is no longe guaranteed to work is indeed a technical
>  fault.

First of all, this hardly the only proposal which could adress that
concern (see other proposals below) and second of all, it's not
necessarily true.

Off the cuff, no error checking:

docdir() { 
  dirname $(grep "/doc/$1/copyright\$" /var/lib/dpkg/info/$1.list")
}
cddoc() {
  cd $(docdir $1)
}

Now we're back to a single probe.  We're just probing the database,
not the filesystem.

And this opens up new possibilities.  What if we add better support
for multiple locations of "/usr/doc" type stuff in general?  The local
sysadmin could suddenly create private packages to install in
/usr/local (including /usr/local/doc), safe from conflict with
whatever we might do, and not even notice.  Third party vendors could
go wild in their little patches of /opt.

>  Chris> And in any case, it's not one location vs. two.  It's more
>  Chris> like three or four vs. four or five.  We have man pages, info
>  Chris> files, built-in help systems, dwww and dhelp, oddballs like
>  Chris> gnome-help, and, finally, as a point of last resort (at least
>  Chris> for non-masochists), we have the all-too-often useless
>  Chris> /usr/doc area.

>         The only one in consideration here is the /usr/doc area. 

No, the only area *you* are considering is /usr/doc.  I am considering
the whole system.  If we had all the documentation in one place and
one place alone, I would never have opposed this proposal in the first
place.  Although, the more I ponder the situation, the more glad I am
that I did.

[symlink disk space]

>         It is not, IMHO, a flaw. The Debian installation requires hard
>  drive space is a requirement, not a flaw. Same here. 

It is a flaw if the use of disk space is gratuitous and doesn't
provide enough benefit to justify its use.

>  Chris> said that it was a technical flaw.  Objecting that it's a
>  Chris> minor flaw doesn't make it not a flaw.

>         Calling a requirement a flaw does not make it a flaw either.

Calling it a requirement doesn't make it not a flaw either.

Frankly, this whole proposal smacks of panicked quick-hack to me, and
I don't think the situation is dire enough to justify panic; I see at
least two other viable short-term alternatives:

  1) stick with /usr/doc till potato is out (I thought this was the
     original plan), and

  2) migrate packages willy-nilly, and support two locations as long
     as we have to (obviously what some expected).

Personally, I still think 1) is the best choice.  Potato is going to
be violating the FHS here, I think it's clear, why not just go ahead
and violate it good and hard? Stick with /usr/doc until we have a
stable release, and not waste time messing around with setting up all
these fancy symlinks yet.  Then maybe we won't have to.

If we stick with /usr/doc, then long term (i.e. post-potato-release),
we again have several options:

  a) this proposal (the "stop-gap")
  b) willy-nilly (the "easy way")
  c) accept multiple locations (the "hard way")
  d) automated migration (the "deus ex machina")
  e) the one I didn't think of ("Schroedinger's cat")

Despite your snide comments about debating this for decades, I think
that one of the things that makes Debian stand out is that we *do* try
to take the time to do things right.  And that's why I'm dubious about
a stop-gap.  I'm also concerned that we may be stuck with these
symlinks for much longer than we'd expected if we do use them.  The
whole idea of a proposal that proposes a future proposal to fix the
existing proposal (your "policy 4.0.0") makes me very leery.

I think we need to make time our friend, not our enemy, on this one.
-- 
Chris Waters   xtifr@dsp.net | I have a truly elegant proof of the
      or    xtifr@debian.org | above, but it is too long to fit into
http://www.dsp.net/xtifr     | this .signature file.


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to "Eric Weigel" <ericw@bestnet.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #356 received at 40706@bugs.debian.org (full text, mbox):

From: "Eric Weigel" <ericw@bestnet.org>
To: "40706@bugs.debian.org" <40706@bugs.debian.org>
Subject: my two cents
Date: Sat, 24 Jul 1999 22:27:50 -0500
I'm a Debian user.  I use it as part of my ISP operation.

I've always been confused and frustrated about where to find files on
Unix and Linux systems.

For instance, I do work on a FreeBSD system where I regularly have to
deal with configuration files in /etc, /usr/local/etc, /var/smtpd/etc,
/usr/local/www/conf, etc yada yada.

Forget about docs.  If there isn't a man page, it doesn't exist. 
Life's too short for me to keep track of where in hell's half acre
these things are stored.

Debian is a breath of fresh air.  The File System Standard and the
Package Manager together make a world of difference.

The layout is clear and makes sense.  I can actually find things.  I
can tell what's installed and what's not installed.  I can see what
needs what before I commit to a change.

If you want my vote, go for the symlinks from /usr/doc to
/usr/share/doc during the migration.

For one thing, the /doc Alias in Apache won't be broken for any package
(not the case right now)

Once all the packages have been migrated to the new system, /usr/doc
will have nothing but symlinks in it.  When that happens, maybe replace
/usr/doc with a symlink to /usr/share/doc.

Cheers!
Eric




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#40706; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #361 received at 40706@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: Chris Waters <xtifr@dsp.net>
Cc: 40706@bugs.debian.org
Subject: Re: Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Date: 25 Jul 1999 02:58:32 -0500
Hi,

        [I think, since this is a dead proposal, there is not much
        point carrying out what has become a nit picking discussion
        about the nature of flaws and the meannig of requirements. As
        usual, I think we have moved into one of our endless dabates
        that lead to no action, and this line of action is doomed to
        picayune nitpicking. I have nothing firther to say about
        this.] 

>>"Chris" == Chris Waters <xtifr@dsp.net> writes:

 Chris> Manoj Srivastava <srivasta@debian.org> writes:
 >> The fact that a single probe into the location derived using
 >> the pacjage name is no longe guaranteed to work is indeed a technical
 >> fault.

 Chris> First of all, this hardly the only proposal which could adress
 Chris> that

        Your point? This is one of the few discussed so far that does.

 Chris> concern (see other proposals below) and second of all, it's not
 Chris> necessarily true.

 Chris> Off the cuff, no error checking:

 Chris> docdir() { 
 Chris>   dirname $(grep "/doc/$1/copyright\$" /var/lib/dpkg/info/$1.list")
 >> 
 Chris> cddoc() {
 Chris>   cd $(docdir $1)

        Firstly, this has to be in every users environemnt, and thus
 needs be written for all shells out there.  So, taking an average of
 2.57 users per system (I am making the figures up), with about 25%of
 the 7million Linux boxes out there (let us round down to one
 million), you wqant 2.5 million environments to be so
 modifed. Brilliant. 

 Chris> Now we're back to a single probe.  We're just probing the
 Chris> database, not the filesystem.

        Still does not answer less /usr/doc/<package>[TAB]

 Chris> And this opens up new possibilities.  What if we add better
 Chris> support for multiple locations of "/usr/doc" type stuff in
 Chris> general?  The local sysadmin could suddenly create private
 Chris> packages to install in /usr/local (including /usr/local/doc),
 Chris> safe from conflict with whatever we might do, and not even
 Chris> notice.  Third party vendors could go wild in their little
 Chris> patches of /opt.

        Vapourware. This is not a workable proposal, IMHO


 Chris> And in any case, it's not one location vs. two.  It's more
 Chris> like three or four vs. four or five.  We have man pages, info
 Chris> files, built-in help systems, dwww and dhelp, oddballs like
 Chris> gnome-help, and, finally, as a point of last resort (at least
 Chris> for non-masochists), we have the all-too-often useless
 Chris> /usr/doc area.

 >> The only one in consideration here is the /usr/doc area. 

 Chris> No, the only area *you* are considering is /usr/doc.  I am
 Chris> considering the whole system.  If we had all the documentation
 Chris> in one place and one place alone, I would never have opposed
 Chris> this proposal in the first place.  Although, the more I ponder
 Chris> the situation, the more glad I am that I did.

        Actually, you are the one who expanded this. The proposal (and
 not just I) concerned only /usr/doc, sionce we have other aspects of
 the FHS transition underf control. You are the one who has widened it
 to a blue sky project. 

 Chris> [symlink disk space]

 >> It is not, IMHO, a flaw. The Debian installation requires hard
 >> drive space is a requirement, not a flaw. Same here. 

 Chris> It is a flaw if the use of disk space is gratuitous and doesn't
 Chris> provide enough benefit to justify its use.

        gratuitous? Not enough benefit? 

 Chris> said that it was a technical flaw.  Objecting that it's a
 Chris> minor flaw doesn't make it not a flaw.

 >> Calling a requirement a flaw does not make it a flaw either.

 Chris> Calling it a requirement doesn't make it not a flaw either.

        I see. Word games. 

 Chris> Frankly, this whole proposal smacks of panicked quick-hack to me, and
 Chris> I don't think the situation is dire enough to justify panic; I see at
 Chris> least two other viable short-term alternatives:

 Chris>   1) stick with /usr/doc till potato is out (I thought this was the
 Chris>      original plan), and

        Too late. The FHS is now policy. I am not going to go into
 freeze with policy violating packages. You can do as you wish. 

 Chris>   2) migrate packages willy-nilly, and support two locations as long
 Chris>      as we have to (obviously what some expected).

 Chris> Personally, I still think 1) is the best choice.  Potato is going to
 Chris> be violating the FHS here, I think it's clear, why not just go ahead
 Chris> and violate it good and hard? Stick with /usr/doc until we have a
 Chris> stable release, and not waste time messing around with setting up all
 Chris> these fancy symlinks yet.  Then maybe we won't have to.

 Chris> If we stick with /usr/doc, then long term (i.e. post-potato-release),
 Chris> we again have several options:

 Chris>   a) this proposal (the "stop-gap")
 Chris>   b) willy-nilly (the "easy way")
 Chris>   c) accept multiple locations (the "hard way")
 Chris>   d) automated migration (the "deus ex machina")
 Chris>   e) the one I didn't think of ("Schroedinger's cat")

 Chris> Despite your snide comments about debating this for decades, I think
 Chris> that one of the things that makes Debian stand out is that we *do* try
 Chris> to take the time to do things right.  And that's why I'm dubious about
 Chris> a stop-gap.  I'm also concerned that we may be stuck with these
 Chris> symlinks for much longer than we'd expected if we do use them.  The
 Chris> whole idea of a proposal that proposes a future proposal to fix the
 Chris> existing proposal (your "policy 4.0.0") makes me very leery.

 Chris> I think we need to make time our friend, not our enemy, on this one.


        We are also known for debating things endlessly, and then ot
 doing anything. I think this is the way we are going down.

        manoj
-- 
 To a Californian, all New Yorkers are cold; even in heat they rarely
 go above fifty-eight degrees.  If you collapse on a street in New
 York, plan to spend a few days there. From "East vs. West: The War
 Between the Coasts
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 sent to Julian Gilbey <J.D.Gilbey@qmw.ac.uk>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Roland Rosenfeld <roland@spinnaker.de>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #366 received at 40706-done@bugs.debian.org (full text, mbox):

From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>
To: 40706-done@bugs.debian.org
Subject: This is now solved
Date: Thu, 22 Feb 2001 00:01:17 +0000
This has been solved long ago; closing the bug report.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

         Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
       Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/



Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 18 20:45:02 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.