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

Re: Vanishing /usr/doc symlink



Santiago Vila wrote:
> Joey Hess:
> > I'm not especially concerned with Julian's case, the important point is
> > that fresh installs of woody will never get a /usr/doc directory, and so
> > no symlinks will be made there (since the link creation is done iff the
> > directory exists).
> 
> Exactly, but this is not a tragedy but a good thing. The symlinks
> exist to support partial upgrades from slink to potato and from potato
> to woody. Every package in woody will use /usr/share/doc so we don't
> need the symlinks anymore in a fresh install.
> 
> > This will result in inconsistencies between debian
> > systems that were freshly installed and those that were upgraded, and I
> > think it will lead to some confusion amoung our users.
> 
> 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.

> 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/. 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.

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.

-- 
see shy jo



Reply to: