Bug#504880: Disambiguate "installed" for packages
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?
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 while its dependencies are unsatisfied, and it is
possible to replace a package whose dependencies are satisfied and
which is properly installed with a different version whose
dependencies are not and cannot be satisfied; when this is done the
depending package will be left unconfigured (since attempts to
configure it will give errors) and will not function properly.
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.
> - 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.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: