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 [EMAIL PROTECTED]
