[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: