Re: dpkg upgrade/downgrade dependency problem
On Mon, 13 Apr 1998, Juan Cespedes wrote:
> On Mon, Apr 13, 1998 at 07:16:41PM -0600, Jason Gunthorpe wrote:
> >
> > On Mon, 13 Apr 1998, Juan Cespedes wrote:
> >
> > > I'm trying to fix Bug#1797,#5639,#6842... (i.e., the famous
> > > dependencies problems in dpkg)
> > >
> > > Is anyone else working on this?
> >
> > 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.
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.
Do not add more conditions to the unpacking stage without giving serious
consideration to what the side-effects will be.
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.
> > If I read the bug reports correctly, dpkg allows you to configure things
> > when other packages dependencies on those things is unmet.. Which means it
> > does not inspect reverse dependancies and reverse provide dependancies.
>
> Hmm... no, not exactly.
>
> (ie, if you have a lot of packages which depend on
> "libc6 (>= 2.0.92)", and you have libc6_2.0.92 installed, and try to
> install libc6_2.0.91, it will let you do it without even a warning.
Isn't this a specific case of what I said? Dpkg allows you to configure
libc6_2.0.91 even though libc6-doc (for instance) depends on some other
version. There are even more complex variations involving provides and
other things. (APT check for all of these, I do have some idea of the
problem, just not the extent)
> IMHO, the correct way to handle this (and the only way to meet
> all the dependencies) is to forbid that installation, ie, not even
Meeting all dependencies at all times is not a trivial task, the
dependency network has become extremely complex, introducing things like
you propose could easially make groups of packages uninstallable. Also, in
many cases it can be a fallacy, for instance, unpacking but not
configuring a package is just as harmfull to it's reverse dependents as is
unpacking the wrong version.
We went through alot of pain developing the ordering routine used in APT,
it deals with an extremely large range of situations and prevents as much
dependency breakage as possible, but even so, some dependencies DO break
for some of the time and that is part of the expected and desired
operation.
Jason
--
To UNSUBSCRIBE, email to debian-dpkg-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: