Bug#42477: PROPOSED} delay the /usr/doc transition till after potato

[Mike Goldman <whig@by.net>]

I observe that several very large packages have already moved to
/usr/share/doc.  Moving them back to /usr/doc will require not
inconsiderable time and inconvenience.  This would be in itself not
cause for objection if it were a step forward.  However, it is clearly
our goal eventually to have all packages use /usr/share/doc, if not
before then after potato releases.  Thus such packages must be rebuilt
and uploaded not once, but twice.  Doubly annoying, and for an end
result which is just status quo for these packages.

On the other hand, it is clearly not desirable that some packages use
/usr/doc and others /usr/share/doc.  This is beyond inconvenient for
end-users, it guarantees confusion for many who will not be familiar
with our policy changes, and thus unable to locate the documentation for
a package.

I happen to disagree very much with the symlink proposals I have thus
far seen, as well.  While it may be convenient for users to access the
documentation as though it were in /usr/doc, when it had in fact moved,
there is just no getting around the fact that things occasionally *do*
move, and for good reasons - retaining symlinks perpetually would just
not be a good thing.  Sooner or later, we have to tell our users that
the files they are looking for are in a new place, in such a way which
does not create confusion.

A way to force all packages to use /usr/doc or /usr/share/doc
exclusively can be automatically performed by dpkg, or by a script which
may be executed at install time or periodically.  The directory which is
not thus used for docs may contain a single README file, explaining that
the documents sought may be found in the other location.

Given then a choice between automatically moving all docs back to
/usr/doc or moving all legacy packages to /usr/share/doc, I would choose
the latter, since this is compliant with FHS which is our eventual goal.

Therefore, I formally object to this proposal.