Re: dpkg upgrade/downgrade dependency problem
On Mon, Apr 13, 1998 at 02:23:29AM -0600, Jason Gunthorpe wrote:
>
> On Mon, 13 Apr 1998, Juan Cespedes wrote:
>
> > On Mon, Apr 13, 1998 at 07:16:41PM -0600, Jason Gunthorpe wrote:
> > >
> > > If you do make any changes please consider applying them only to the
> > > configuration stage - for instance aborting a configuration if other
> > > dependencies are broken?
> >
> > No, that won't work. The problem is that dpkg allows you to
> > upgrade or downgrade a package without checking if the new installed
> > package has any dependency problems which weren't there in the
> > previously-installed one.
>
> If you do this you will seriously complicate APT and make multi-cd
> installations, diskette installations and others extremely hard.
I'm not sure about this. Could you give me an example of how
this will break something?
> Furthermore I strongly suspect all dselect methods will simply cease to
> function as a much larger percentage of packages will suddently have fatal
> unpacking errors. Consider the provided mount method that just does dpkg
> -iGROBE -- how will it ever unpack libc6-doc before libc6? En-mass
> deconfigures could also create quite the risk of damanging the system.
It's just the opposite: if option "-B" is NOT used, it won't
unpack libc6 before libc6-doc because libc6-doc depends on
"libc6 (= whatever)" and you are about to install a new version.
However, with option "-B" (== --auto-deconfigure), it will unpack
libc6, configure it, but deconfigure libc6-doc, because it depends on
a version of libc6 which is not installed.
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.
> Do not add more conditions to the unpacking stage without giving serious
> consideration to what the side-effects will be.
OK, I'm thinking about it, and if I make the changes, I won't
submit them without severe testing.
> 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.
Please tell me any examples on how this would break something.
I still think it's the correct way to do this.
--
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: