Bug#504880: Disambiguate "installed" for packages
On Sat, Feb 14, 2009 at 12:16:16PM -0800, Russ Allbery wrote:
> Kurt Roeckx <kurt@roeckx.be> writes:
>
> >> + If there is a circular dependency among packages being installed
> >> + or removed, installation or removal order honoring the
> >> + dependency order is impossible, requiring the dependency loop be
> >> + broken at some point and the dependency requirements violated
> >> + for at least one package. Packages involved in circular
> >> + dependencies may not be able to rely on their dependencies being
> >> + configured when being configured or removed depending on which
> >> + side of the break of the circular dependency loop they happen to
> >> + be on. If one of the packages in the loop has no
> >
> > A previous proposal had two times unpacked instead of configured, and
> > I'm not really sure why you changed it.
>
> Based on the subsequent discussion, I thought this was more accurate, but
> it's possible that I misunderstood.
>
> > They can't rely on it being configured, so the text is not wrong.
> >
> > But the previous text has atleast two other things that it indirectly
> > states that you can't rely on in case of circular dependecies:
> > - If you're being configured wether you're dependend-on package
> > is unpacked. You now only say it's not configured.
>
> Why can't you rely on this?
I don't know if we can rely on it or not.
> The definition of Depends says that it doesn't apply to the unpack state
> at all:
>
> A `Depends' field takes effect _only_ when a package is to be
> configured. It does not prevent a package being on the system in an
> unconfigured state [...]
So it can be in unpacked state, but it doesn't have to be.
> Therefore, why would there ever be a situation when a package is being
> configured and its dependencies aren't yet unpacked? You can always
> unpack all the relevant packages first, as discussed in the next
> paragraph:
>
> For this reason packages in an installation run are usually all
> unpacked first and all configured later; this gives later versions of
> packages with dependencies on later versions of other packages the
> opportunity to have their dependencies satisfied.
>
> If this is not true, then there's something more fundamentally wrong with
> the current text that needs to be fixed.
I have no idea what exactly dpkg's behaviour is in case it breaks a
dependency loop. Note that it says usually. It might unpack the depended-on
package already, I don't know. I would say that policy atleast isn't clear on
what can be expected when a dependency loop is broken.
> > - When you're being unpacked that the dependend-on package is
> > unpackaged which might be important to maintainer scripts. During
> > the unpack state all maintainer scripts can potentially be called,
> > taking the error cases into account. All but postinst can be called
> > if there is no error.
>
> I think this is another aspect of the same point above? My understanding
> from the discussion and the clarified text that Raphael sent is that
> postrm can always rely on the depended-on package being unpacked and
> configured and prerm can always rely on it at least being unpacked, even
> in the case of circular dependencies.
As I understand it, the dependency is ignored so you can not rely on
anything you expect for a Depends in case of circular dependencies.
Kurt
Reply to: