Re: dpkg upgrade/downgrade dependency problem
On Mon, Apr 13, 1998 at 06:17:21PM -0600, Jason Gunthorpe wrote:
>
> 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.
Only when some package has been deconfigured. And this would
be very rare.
> 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)).
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,
> -----
> 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.
> 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.
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.
> 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.
It will work after configuring libreadlineg2.
> 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.
> 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).
So, if someone upgrades libc6, it will deconfigure libc6-dev
and libc6-doc. I think it's the Right Way to do it.
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)".
> 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.
I disagree.
> 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.
> 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.
Oh, yes, it knows what it is doing most of the time.
>
> 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.
In this case, APT shouldn't be worried at all.
> > 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.
I said that it will deconfigure a package if
"--auto-deconfigure" is used, but only if that package is
non-essential.
> Notice how this doesn't make things safer? Extend that to any
> situation, how does an autodeconfigure make things safer?
OK, I'm not particulary fond of allowing that option. But
then a package should not be unpacked if it breaks other packages'
dependencies.
> 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.
> 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.
Yes, but people will go on using it. And we should try to let
it as harmless as possible.
--
Juan Cespedes
--
To UNSUBSCRIBE, email to debian-dpkg-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: