Re: Vanishing /usr/doc symlink
Joey Hess wrote:
> Santiago Vila wrote:
> > different != inconsistent. As an example, a Debian system upgraded
> > from slink to potato has the mail spool in /var/spool/mail. A fresh
> > potato install has it in /var/mail. Yes, this means a slink system
> > upgraded to potato is *different* than a fresh potato install, but I
> > would never call this an inconsistency.
>
> People often explore /usr(/share)/doc manually; exploring the mail spool
> is done less often. People will be digging in /usr/doc to look for
> documentation, whereas if you're looking for the mail spool in
> /var/spool/mail and don't find it, you still know where to turn to try
> to find information about where this directory went.
This was just an example to show that just because something is different
does not mean it's inconsistent.
If you still think different==inconsistent, well I disagree.
> > potato users already know that potato is in the middle of a transition
> > from /usr/doc to /usr/share/doc. A user would have to be *very* clueless
> > to be surprised about docs being all in /usr/share/doc in woody.
>
> Where was this documented in potato? It was certianly not documented in
> the base-files motd for potato, which mentions only /usr/doc/.
It was documented "by implementation" at least. If, as you say and I agree,
people often explore /usr(/share)/doc manually, they would have to be
*really* stupid not to realize we are moving to /usr/share/doc.
> I think you're confusing us developers who are throughly tired of
> this whole damn thing (after 3 years!!) with users who have been
> pretty well shielded from it.
I think you underestimate both the intelligence of our users and their
willingness to get rid of compatibility symlinks.
> Bear in mind that if we didn't have to worry about users knowing where
> to look for documentation, we probably would never have chosen this
> transition plan in the first place. The transition plan includes a step
> where the docs are available in both places, and where the documentation
> points users to /usr/share/doc, because that this is supposed to be the
> release where users learn to change their finger macros to the new
> directory. By short-circuiting this you are ignoring the decision of the
> technical committee.
When the transition plan was written, nobody realized that we could
achieve our goal of supporting partial upgrades from slink to potato
and from potato to woody at the same time we could get rid of symlinks
in a fresh woody install.
The *goal* of the transition plan was to avoid the user the need to
look *both* in /usr/doc and /usr/share/doc, and supporting partial
upgrades until all packages have moved. Shipping a distribution with
docs in both places is a way to achieve this goal, but it's not a
required thing for that goal. Since we made /usr/share/doc a "must" in
woody, we can consider the transition complete as far as new installs
are concerned.
I think a fresh woody without /usr/doc is compatible with the goal of
the transition plan, however if you read the transition plan you will
see it's based on some assumptions which are no longer true (for
example, that dpkg does not have some features it has now). Before
saying that such and such is against the decision of the technical
committee, should not the technical committee issue a revised plan?
A fresh woody install should not need symlinks in /usr/doc. Symlinks
are just cruft and we want to get rid of them. They make the install
slower, they waste inodes and cpu time. Why in earth would we want a
fresh woody install having a /usr/doc directory populated by useless
symlinks?
Reply to: