Re: Vanishing /usr/doc symlink
Joey Hess wrote:
> Santiago Vila wrote:
> > > 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.
In either case, where this has to be documented is in woody, and /etc/motd
already refers to /usr/share/doc. Anyway, I agree that a symlink
/usr/doc -> /usr/share/doc would probably help the clueless people.
> > 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?
A much cleaner system, free of cruft, of course.
> We still have to worry about removing all the symlinks in woody+1
> because we still have a large body legacy installed systems.
We already worried about this, do not have to worry again. Every prerm
removes the symlinks if they exist. We just upgrade to woody+1 or
woody+2 and the symlinks should be gone.
> > 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,
Ok, you have a point here, but the waste of inodes still holds.
> 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.
No, of course I can't. It would be like guaranteeing that something is
bug-free. But those who rely on /usr/doc being present are buggy and
should be fixed.
However, there are several people who symlinked /usr/doc to /usr/share/doc
and did not experience any problem (the only problem is doing so before
all packages have moved to /usr/share/doc, this is Julian's initial problem).
Reply to: