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

Bug#40706: usr/share/doc vs. /usr/doc



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


Reply to: