Re: predepends on libc6?
J.J.Troup@comp.brad.ac.uk (James Troup) wrote on 09.12.97 in <[🔎] dmmlnxvz59i.fsf@dcsun4.comp.brad.ac.uk>:
> kaih@khms.westfalen.de (Kai Henningsen) writes:
>
> [ Deleted the part where the doubters once again fail to bother to
> yprove that ldconfig isn't necessary (Hint: the onus isn't on me; I
> don't care anymore, I *know* the policy manual is wrong, if you think
> otherwise, do something about it, either way I'm not going to waste
> more time discussing it) ]
All the time you spent on it was wasted. Assertions don't help anybody.
Note that I _don't_ assert that it's unnecessary (and neither, I believe,
does Richard); I'd just like to learn what's going on. You, obviously,
don't intend to tell, or maybe you don't know.
Ok, let's forget that until someone can aytually say something useful.
> > > [dpkg does ordering on configuration and removal, not install]
> >
> > Aah. Now _this_ is a good (and probably sufficient) point.
>
> [Just out of curiosity, why do you believe me about that? No, never
> mind, forget I asked]
Simple. Once reminded, I remembered that I already knew about that. It's
kind of obvious when you watch dpkg -iGROEB.
> > From this, I'd say that everything needed by dpkg -i MUST pre-depend
> > on any other package that it needs for that functionality used by
> > dpkg -i.
>
> I don't think so. Once gzip Pre-Depends on libc6, it shouldn't be
> possible for dpkg to get into a mess because it's unable to fork
> programs again. The packages you mention below are all essential,
> dpkg can validly assume they'll be installed. And because of their
It can assume they are unpacked, NOT that they are installed, not even
that they are configurable, as you yourself just reminded us. The pre-
depends are to force the right upgrade sequence.
IMHO, any packages needed by dpkg -i extremely-essential-package MUST be
installed one-by-one, never two at once. That's the only way to guarantee
we don't end up unpacking incompatible packages. Every upgrade of one of
these must start from a working system, and end there.
The set of extremely-essential-packages should probably be defined like
this:
1. whatever is needed to dpkg -i dpkg
2. whatever is needed to dpkg -i any-other-already-extremely-essential-
package
(repeat until no more packages get added)
There's lots of essential packages that are not THAT essential. It's
possible to recover from a broken login, for example, as long as you still
have a running root shell. That's essential, but not extremely-essential.
> (If someone's forced the removal of an essential package all bets are
> off, so the only valid issue here is upgrading, as far as I can see)
True, but remember incompatible upgrades. With these packages, it's not
enough that <current state>+X,Y is usable, <current state>+X needs to be
usable by itself or we can't proceed to install Y (the gzip trap)!
It may be that a different strategy would be better than pre-depends, but
we sure need _something_.
> > By the way, shouldn't Pre-Depends: only be used for Essential: yes
> > packages?
>
> No; I think there are valid uses of Pre-Depends for non-essential
> packages.
>
> > I see Pre-Depends: without Essential: in the following packages:
> > libc5, libc6, libreadline2
>
> You can't make shared library packages essential (Policy 2.3.7).
Hmm ... e2fslibsg, comerr2g, ldso are essential - well, ldso is a special
case, and the e2fs stuff is known to be broken. Sounds about right.
> The version I can see (5.004.04-2) has only a Depends. Perl-base is
> Essential and it's Pre-Depends are definitely a good thing, for, I
> hope, obvious reasons.
I've not yet seen that one, but it's probably already on my mirror. The
one I mentioned was the 5.004.02, I believe.
MfG Kai
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: