Bug#69311: PROPOSAL] Finishing the /usr/doc -> /usr/share/doc transition.
On Thu, 24 Aug 2000, Raul Miller wrote:
> On 23 Aug 2000, Manoj Srivastava wrote:
> > > Woody shall have a full /usr/share/doc/ when released, while
> > > allowing for partial upgrades from potato all the way, under the
> > > plan.
>
> On Thu, Aug 24, 2000 at 02:03:06PM +0200, Santiago Vila wrote:
> > The "partial upgrades" issue is a myth. As I said, we have never
> > guaranteed that *every* conceivable partial upgrade will work (because
> > of versioned dependencies on newer packages). Very often, upgrading a
> > package forces the upgrade of some others, and this is not considered
> > as a bug or a deficiency of the system. Do we agree on this?
>
> I disagree that the "partial upgrades" issue is a myth. Your "proof"
> of this "myth" only has relevance where explicit dependencies (or
> conflicts) exist.
Please note that not every dependency or conflict is explicit. You
can't read new manpages using an old enough man-db package, unless you
make a little bit of tweaking in the configuration file, and we don't
speak about "breakage" because of the need of this tweaking.
In either case, there is something important I forgot to mention about
partial upgrades:
If I'm not mistaken, one of the reasons the symlink-on-a-package-basis
plan was accepted was the lack of a way for an ordinary user to make
fully FHS-compliant a system like current potato, which is a mix of
FHS and non-FHS. "If you move things around, dpkg will get very upset"
it was said a lot of times.
Well, with the dpkg in potato this is no longer true, and for most
(if not all) packages still using /usr/doc it is currently possible to
do this:
cd /usr/doc
mv <package> /usr/share/doc
ln -s ../share/doc/<package>
The dpkg in potato will not get confused anymore when you upgrade
<package> to the FHS-compliant version.
I know this will not suddenly convince you or Manoj that the symlinks
are not required anymore in woody, and that the new dpkg makes partial
upgrades acceptable enough (in the sense that those who make a partial
upgrade and need complete FHS compliance may achieve it easily by
hand), but I think it's something which has not been evaluated so far.
BTW: Yes, I want FHS-compliance as soon as possible, but I don't think
the term "impatient" should be used in a negative sense, everybody
should be allowed to be an impatient. Otherwise: What are all those
users who are running potato and need a package or two from woody and
make a partial upgrade. They are impatient as well! They should wait
for woody-in-which-every-package-will-use-/usr/share/doc to be released :-)
> [Aside: we're going to be using "partial upgrades" extensively during
> the development phase of Woody. Introducing breakage would slow down
> the release of Woody, and would interfere with proper testing of the
> rest of the system.]
Please, define "breakage".
> Also, introducing dependencies to manage the /usr/doc/ transition would
> add a whole new suite of problems.
I do not advocate for introducing explicit dependencies, but I think
implicit dependencies would not be such a disaster either.
> If you care to understand those issues, you might want to take a look
> at the debian-ctte traffic from a year ago.
A year ago dpkg did not have an important feature today it has.
> > I'm not saying 79% is as good as 100%, I'm saying that a 79% of
> > converted packages after the upgrade from slink to potato is good
> > enough to consider a modification of the original plan, by letting the
> > two transitions which still have to be done to overlap:
> >
> > 1. Packages use /usr/share/doc. This transition is 79% complete. We
> > expect it to be complete by the time woody is released.
> >
> > 2. Packages do not create any symlinks in /usr/doc.
> > This transition is 0% complete, because it has not even started.
>
> What I don't get is why you're so eager to break things.
Please define "break".
> What problem do we solve by tossing those symlinks?
> Please don't say FHS compliance.
Today's symlinks are tomorrow's bugs. Introducing something which
everybody knows sooner or later it *will* be considered as a bug is
not a bright idea.
Additionally, the upgrade process will be faster if dpkg has not
constantly to execute prerm and postinst scripts which often do
nothing more than creating and destroying symlinks. Have you tried to
install Debian on a 386 lately?
Reply to: