Re: Bug#40706: usr/share/doc vs. /usr/doc
Hi,
Now that policy 3.0.1 is out, we neede to have a means of
tackling the /usr/doc ==> /usr/share/doc transition.
(A) 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 *cawnnot* expect to get FHS compliance in
place by potato.
In any case, the unit we use for upgrading is the package, so
any major changes *have* to be handled at the package level.
Also, evolutionary changes are less dangerous than
revolutinary changes, and cause less bloodshed.
(B) 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 laces, and that is not good.
======================================================================
I propose that there be a syymlink from /usr/doc/<package> ->
/usr/share/doc/<package>, managed by the p[ackage itself. This is how
it works:
a) 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>)
b) 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.
To the objection that it shall cause package to be modified
twice, I say that
a) this is a complex transition,
b) packages need be modified fro FHS compliance anyway
c) the removal of the symlink shall be in the future, and packages
can expect changes whenever policy changes in the forst place.
I think the handicap of having to remove a line from the rules
file (and no action for people who use helper packages), is far
offset by the benefits of this solution.
manoj
looking for seconds
--
Walking on water wasn't built in a day. Jack Kerouac
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 to: