Re: Vanishing /usr/doc symlink
Santiago Vila wrote:
> > 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.
As an example it's not very useful. I'm not interested in quibbling over
your definitions of words. I think that having two different versions of
woody installs with a major different of this sort is a bad thing, from
perspectives of elegance, design, documentation, etc. That's all.
> > 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.
Only if they happened to notice /usr/share/doc, and happened to have
packages installed that had a significant number of symlinks in there
(potato was at what, 50% or so conversion)? And happened to draw the
correct conclusion from that.
> > 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.
I have a lot of respect for our users, I'm sure they will manage no
matter what we do. I would, however, like them to continue to have
respect for us, and we have to produce a good release to maintain that,
and I do not feel that doing things as you desire will lead to the best
possible Debian release.
> 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.
And what does that buy us exactly? We still have to worry about removing
all the symlinks in woody+1 because we still have a large body legacy
installed systems. I won't use the dreaded "inconsistency" again, but
this major difference between two sets of woody systems will just make
the upgrade to woody+1 that little bit more complex; it will be one more
variable we have to worry about. So what's the gain?
> 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?
I wouldn't mind hearing their thoughts. I am not interested much in
running for them for a decision since they have historically been slow
to react.
> 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.
Symlinks waste inodes, but by the time dpkg has launched a postinst
script, run sh, the script has determined it is configuring the package,
and begins to check to see if /usr/doc is there so it can make the
symlink, the additional call to 'ln' it will do if the directory is
there is not going to result in any more significant time spent at
all[1]. It's having these useless postinsts in all the packages that is
really slowing things down, and we can't remove them for woody, so
having them exercise an alternate code path on half of the woody systems
seems an exercise in pointlessness.
Can you even guarantee that all the postinsts in Debian will deal
correctly with a missing /usr/doc? That code path has not had much
testing.
--
see shy jo
[1] Except for in postinsts written by Manoj, perhaps.
Reply to: