Re: finishing up the /usr/share/doc transition
On Mon, 1 Jan 2001, Joey Hess wrote:
> Santiago Vila wrote:
> > No, we don't *need* any script to do this. One thing is that dpkg
> > allows this to be done and another different one is that we *have* to
> > do it. We agreed to make the transition on a per package basis. If we
> > consider the transition almost finished and we want an empty /usr/doc
> > we have just to *stop* requiring symlinks in maintainer scripts (which
> > is something that we would do sooner or later). Once we stop making
> > symlinks in /usr/doc, this directory will be emptied by itself,
> > cleanly, and without risking the integrity of the system by complex
> > scripts.
>
> Take another look at where we are now. If 6 people fix one package a
> day until woody is frozen, we might just manage to convert all packages
> that do not yet use /usr/share/doc. If that is done, we only have to wait 2
> more releases of debian until the transition is complete.
First, there is no hurry for this. Second, it would probably take only
one more release if we stop using symlinks right now. I already made a
policy proposal to stop using symlinks, but there were objections from
Manoj and Raul, what do they think about this single-script idea which
is clearly against what the T.C. decided? (I guess they are on vacation).
I do not follow your argument, anyway: If 6 people fix one package a
day until woody is frozen, everything will be (physically) in
/usr/share/doc at release time. In such case it should be extremely
easy to remove /usr/doc by hand *if one wants to*. Why do you need a
complex script then? I think it is much better to leave this to the user's
discretion.
> On the other hand, if we use a script now, we can be done tomorrow.
You can be done today if you want (just use your script in *your*
system, at your *own* risk), but this does not necessarily mean we
have to risk hundreds of thousand of systems out there which do not have
a real need to be converted in a single step.
> As for risking the integrity of the system with complex scripts, take a
> look at the tremendous number of ways that people have managed to screw
> this up doing it one package at a time (I just discovered a package that
> puts files in /usr/doc/foo with a symlink /usr/share/doc/foo to it;
> completly backwards from what policy requires.).
Yes, I *always* thought these symlinks were a really bad idea, but
the solution is to stop requiring them, not writing yet another script.
> Perhaps a single script is actually likely to be better?
Perhaps no script at all and stop requiring symlinks is even better
than a complex script.
Reply to: