Bug#183470: dpkg: can't dependencies be checked before overwriting?

[Martin Quinson <Martin.Quinson@tuxfamily.org>]

reopen 183470
retitle 183470 dpkg: can't dependencies be checked before unpacking?
severity 181491 normal
merge 183470 181491
thanks

> On Wed, Mar 05, 2003 at 07:44:45AM +0800, Dan Jacobson wrote:
> > Package: dpkg
> > Version: 1.10.9
> > Severity: minor
> > File: /usr/bin/dpkg
> > 
> > Can't dependency problems be checked before the user blows away his
> > good version?
> > 
> > # dpkg -i /tmp/gnucap_0.33-2_i386.deb 
> > (Reading database ... 214178 files and directories currently installed.)
> > Preparing to replace gnucap 1:0.33-1 (using /tmp/gnucap_0.33-2_i386.deb) ...
> > Unpacking replacement gnucap ...
> > dpkg: dependency problems prevent configuration of gnucap:
> >  gnucap depends on libgcc1 (>= 1:3.2.3-0pre2); however:
> >   Version of libgcc1 on system is 1:3.2.2-0pre8.
> >  gnucap depends on libstdc++5 (>= 1:3.2.3-0pre2); however:
> >   Version of libstdc++5 on system is 1:3.2.2-0pre8.
> > dpkg: error processing gnucap (--install):
> >  dependency problems - leaving unconfigured
> > Errors were encountered while processing:
> >  gnucap
> > 
> > Yes, I know about apt. I'm wondering why you can;t move the check just
> > a little earlier in the sequence of events.
> 
> It's a chain of events based on definitions. gnucap depends on libgcc1,
> which by definition means that libgcc1 needs to be installed before
> gnucap can be configured. That does not mean it needs to be installed
> before gnucap is. That would be a pre-depends (a depend which must be
> satisfied before a package is even unpacked).
> 
> Making your change would break all installs, even with apt and dselect.
> 
> It's not uncommon to make use of this as a feature, which is why we have
> the difference between depends and pre-depends.

I guess you missunderstood. I think that Dan wants the "unpacking
replacement gnucap" line coming after the "dependency problem" check. This
way, if a package is uninstallable, dpkg will notice it and refuse to do
anything, in contrary to the current behaviour which is to unpack the
package, see that the package is in fact uninstallable, and leave the system
with a package unpacked but not configured yet.

I agree, it would be cleaner.

I did retitle this bug to make this point more clear. And I did merge it
with another repport asking for the same thing.

Bye, Mt.

-- 
Nos péchés sont têtus, nos repentirs sont lâches
          --- Ch.Baudelaire, Les fleurs du mal