Bug#203650: Poor recommendation in dpkg-statoverride section
On Mon, Aug 04, 2003 at 10:37:53PM -0500, Adam Heath wrote:
> On Tue, 5 Aug 2003, Herbert Xu wrote:
> > On Mon, Aug 04, 2003 at 11:05:54AM -0500, Adam Heath wrote:
> > > You're confusing pre-depends and essentialness.
> >
> > What about the case if adduser needs a new feature in useradd and
> > thus uses a versioned dependency on passwd. This means that the new
> > adduser can be unpacked before the new passwd is unpacked or
> > configured since it's only a plain old dependency.
> >
> > As an unversioned pre-dependency is fulfilled as long as a package
> > was previously configured, this will allow packages declaring
> > pre-dependencies on adduser to run their preinsts even though the
> > new passwd is not yet available, rendering adduser useless.
>
> No. If foo pre-depends on bar, dpkg guarantees that bar is in a
> configured state, before it even considers doing anything with foo.
> And foo can only be in a configured state, if all it's normal
> deps(conflicts/etc) are sane.
>
> Please, get your dependency resolution straight. This is not rocket
> science.
Adam, the depisok() function in dpkg 1.10.10 says:
* allowunconfigd should be non-zero during the `Pre-Depends' checking
* before a package is unpacked, when it is sufficient for the package
* to be unpacked provided that both the unpacked and previously-configured
* versions are acceptable.
The code in this function and in predeppackage() appears to agree.
Furthermore, this behaviour is what is described in policy. Herbert
seems to be quite correct.
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: