Re: dpkg upgrade/downgrade dependency problem
On Mon, 13 Apr 1998, Juan Cespedes wrote:
Okay, I think I can explain this now - it's not 3am :>
First off, if you implement what you say, and use -B then I think that
will be enough to deal with lack of ordering, and I am now certain that
deconfiguring is enough to remove it as a loop causing factor. Though note
that the methods will have to call dpkg --configure --pending when they
are done.
This still doesn't make it a good idea.
When doing the ordering code I toyed with doing exactly this, but rejected
the idea because it doesn't really do anything positive.
> Other example:
> $ dpkg -s bc
> Package: bc
> Version: 1.04-4
> Depends: [...], libreadlineg2 (>= 2.1-4), [...]
> [...]
> $ dpkg -s libreadlineg2
> Package: libreadlineg2
> Version: 2.1-8
>
> What would happen if I try to install libreadlineg2_2.1-2?
> The "bc" dependencies won't be satisfied, so dpkg shouldn't let me do
> that, unless option "--auto-deconfigure" is used ("Install even if it
> would break some other package"). In this case, I think "bc" should
> be deconfigured.
This is a fallacy. The way the packaging system has been working for some
time rules out your logic. Let me try to explain.
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.
-----
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.
Now, back to your example. Let's consider a slightly different situation
first.
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.
Your statement was that "If I install libreadlineg2 2.1-3 then bc's
dependencies will not be satisfied and dpkg should not let me do that"
1) 'dependencies will not be satisfied' is another way of saying the
package does not work.
2) 'dpkg should not let me do that' - if you wish to make this true then
dpkg should not let me unpack and not configure 2.1-9 because that
also makes the package not work.
Now, lets consider the possibility of applying a deconfigure step so that
all configured packages are always working. When I unpack libreadline2g
(any version!) I will have to deconfigure bash (!!), bc and others so that
they are never configured and not working.
Obviously this is not possible, upgrading something like libc6 would
cripple the entire system.
The association I am trying to create here is that a broken dependency on
a unpacked package is no different than a good dependency on an unpacked
package. Trying to fix only one situation does virtually nothing for the
stability of the system and fixing both destroys the usability of the
system. Furthermore the only reason fixing one does not destroy usability
is because of the rareness of it actually being invoked.
Even my suggestion of not allowing the configure is a bad one and does
nothing to make things safer.
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.
No matter where you put a check it will be non-ideal.
> > Placing an error on the configure phase does not alter the semantics of
> > the unpacking phase but does provide at least a warning that something has
> > gone wrong.
>
> Yes, but it's a bit odd to leave unconfigured one package
> because other packages' dependencies aren't met. And That's why
> option "--auto-deconfigure" is there. It is used by dselect, and I
> think it should be used by apt.
APT makes 0 use of any of dpkg's automatic features. Things arranged so as
to defeat all of them.
> Please tell me any examples on how this would break something.
> I still think it's the correct way to do this.
Downgrade libreadlineg2 - you propose that dpkg will happily deconfigure
bash. Notice how this doesn't make things safer? Extend that to any
situation, how does an autodeconfigure make things safer?
Has anyone considered that this is not a dpkg bug - but is a feature?
Things like this are what allow us to do things like delayed configuration
and have a complex dependency network.
I think that basically dpkg has been cast into two roles that in some
cases are mutually exclusive - as a low level package tool and as an all
purpose command line UI to the package system. It does a good job as a low
level package tool, but I think it's a poor command line UI.
Jason
--
To UNSUBSCRIBE, email to debian-dpkg-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: