Re: dpkg upgrade/downgrade dependency problem
On Tue, 14 Apr 1998, Juan Cespedes wrote:
> > First, you must accept these three points - they describe some of how
> > things operate:
> >
> > When a package is in the unpacked state dependencies are automatically
> > severed. That is dpkg --deconfigure libreadlineg2 makes bc unusable.
> > This is the first thing to accept.
> >
> > Wen a package has unmet dependencies it can be deconfigured, removed
> > and upgraded. That is, the *rm scripts must function. This means that the
> > *rm scripts can not depend on any dependencies being true.
> > This validates the action of removing packages with unmet dependecies.
> >
> > The only things that inhibit unpacking are items that are strictly
> > forbidden - violating a conflicts and unmet forwards predepends.
>
> So you say I should treat "depends:" and "pre-depends:" in a
> different way. Well, that is an option. Many of the bug reports
> about this are about ensuring we shouldn't leave "bash" unuseable by
> installing an old version of libreadlineg2. (bash is essential, and so
> it predepends on libreadlineg2 (>= some version)).
Read that again carefully. This section describes how things work NOW -
not how you should make them work. Notice I specificly said 'forwards
predepends' - that excludes reverse predepends - it is perfectly
fine to unpack a new package and wreck a predepend on it (reverse
predepend).
> If someone (mistakenly) tries to install a version of a program which
> can make an essential program fail, dpkg should not allow them to even
> unpack that program. However,
By that logic It shouldn't allow someone to install a version of a program
and leave it unconfigured - BUT IT DOES! dpkg does very little to protect
essential packages.
> > If you don't like one of the above then that is a separate issue, but give
> > your argument alot of consideration first, they are how things have been
> > working for quite a long time.
>
> No, they aren't done that way now. That's why I wanted to fix
> it. In the current version, dpkg can left Pre-Dependencies unmet
> without even a warning.
Please tell me exactly how and which of the three points above are not
true now - it's very important. Check your facts, because I have verified
each of the above.
> > Lets unpack libreadlineg2 2.1-9. Once we do that bc stops working (point
> > #1) however we can safely alter bc's state (point #2)
> >
> > Now, lets look at your case, unpack libreadlineg2 2.1-3. Once we do that
> > bc stops working (point #1 combined with the unmet dependency) however
> > again, we can safely alter bc's state.
> >
> > Notice that both actions have identical results on the system.
>
> Yes, but in one of the cases, bc will no longer work (even
> after configuring libreadlineg2) because it depends on a version of
> libreadlineg2 that is not installed.
That is an irrelivent point - at the time of unpacking dpkg cannot be
assured that libreadline will ever be configured or even that it can be
configured.
> It will work after configuring libreadlineg2.
See, this is the entire flaw in your reasoning - dpkg was specificly
designed so that each action is concerned only with it's own effects and
not th effect on the system as a whole.
When unpacking, dpkg cannot know that the package is configurable, it was
actually specificly designed to ALLOW the case of unpacking an
unconfigurable package.
Though you are right that 'after configuring libreadlineg2 bc will work'
but you cannot say that libreadlineg2 can ever be configured so the
statement is pointless as a justification for differentiating the two
cases.
To see what I mean think about this:
A new bc will be installed that depends on the new libreadlineg2
Wow - I just justified why you should not bother checking that unpacking
the new libreadlineg2 broke bc because it will be 'ok later'. Of course I
can't prove that in all cases bc will be installed. You also
can not prove that libreadelineg2 will ever be configured.
> > Now, lets consider the possibility of applying a deconfigure step so that
> > all configured packages are always working.
>
> I don't want them to be always working. However, I would like
> to have them working after configuring all the packages.
dpkg has no decision point where it can say this about anything, and again
you are operating under the strange idea that configuring has something to
do with the decisions at the unpacking phase - if this were so it would
look at normal depends while unpacking.
> > When I unpack libreadline2g
> > (any version!) I will have to deconfigure bash (!!), bc and others so that
> > they are never configured and not working.
>
> bash will never be deconfigured unless the
> "--force-remove-essential" flag is set.
> > Obviously this is not possible, upgrading something like libc6 would
> > cripple the entire system.
>
> What will break? What packages depend on a specific version
> of libc6? Only libc6-dev and libc6-doc. (BTW: the libc6-doc
> dependency has been reported as Bug#21045).
Well, you see, this was a thought example, go re-read my original email.
The point of this section was to illistrate that checking for reverse
dependencies is only a small portion of the total puzzle to ensuring a
system that always works. To do it completely requires the actions I go on
to suggest and explore. You are supposed to appreciate that you are not
adding much in the way of safety with your new check.
> However, if someone tries to downgrade libc6 to, say, version
> 2.0.4, dpkg shouldn't let you do it because sysvinit has a line
> "Pre-Depends: libc6 (>= 2.0.5c-0.1)".
PreDepends are irrelevent at any point other than the unpacking phase [as
is now] if you change the meaning you should really discuss it on policy.
> > Trying to fix only one situation does virtually nothing for the
> > stability of the system
>
> It prevents many errors. Try installing "libreadlineg2_2.0-1"
> and see how bash stops working without even a warning.
Try unpacking libreadlineg2_2.0-10 and see how bash stops working without
even a warning. dpkg allows you to do lots of things that are unsafe - why
are we singaling out only one?
> > The basic problem is that dpkg is not really able to deal with reverse
> > dependencies because it has no idea what will happen in a few seconds - it
> > has no concept of heading toward a destination and hence cannot validate
> > that what it is doing is ok with respect to where it is going.
>
> Oh, yes, it knows what it is doing most of the time.
No it doesn't, that is the real issue behind this bug: dpkg checks only
what is relevent to the operation at hand and nothing more. You want to
make it check things that are not relevent to the operation it is
performing. This is major change of direction for dpkg.
> > APT makes 0 use of any of dpkg's automatic features. Things arranged so as
> > to defeat all of them.
>
> In this case, APT shouldn't be worried at all.
If you add this check the apt will fail because it is not always possible
to get the order your enforce without falling back to unconfigures and the
unconfigures are not required because APT knows that the dependency will
be okay a few operations down the road.
> > Has anyone considered that this is not a dpkg bug - but is a feature?
>
> No. dpkg should check all the dependencies, or check no
> dependencies at all. Checking just some of them can't be a feature.
It DOES check all dependencies, quite simply reverse dependencies are not
relevent to any of the stages, so it has no reason to check them.
If you add checks for reverse dependencies then I think dpkg will no
longer be usefull in the same sense it was before. Also, there are many
other things you should enforce because they are in essence the same as
checking reverse dependencies.
You have to realize that in fixing this bug you take dpkg further away
from being a low-level tool and closer to being an end user interface. In
doing so we loose a little bit of the lowlevel tool. [And it's still a
really bad user interface]
Do you really think the gains in usability are worth the sacrifice of
flexability? I don't think you make things much safer and you do give up
quite a bit.
I think it would be best just to show a warning when configuring, and make
sure that audit can detect the situation.
Jason
--
To UNSUBSCRIBE, email to debian-dpkg-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: