Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition

[Kristoffer.Rose@ENS-Lyon.FR]

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>