Bug#504880: Disambiguate "installed" for packages
Colin's original patch had one second from Raphael and it looks good to me
as well, so I think we're about ready to commit this for the next Policy
release. I also added this hunk based on the bug discussion:
@@ -4285,8 +4285,8 @@ Build-Depends: foo [!i386] | bar [!amd64]
removal order honoring the dependency order can't be
established, dependency loops are broken at some point
(based on rules below), and some packages may not be able to
- rely on their dependencies being present when being
- installed or removed, depending on which side of the break
+ rely on their dependencies being unpacked when being
+ unpacked 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 postinst script, then the
cycle will be broken at that package, so as to ensure that
The remaining open issue is this:
Raphael Hertzog <hertzog@debian.org> writes:
> On Sun, 09 Nov 2008, Colin Watson wrote:
>>>> There is also:
>>>> The `Depends' field should also be used if the `postinst',
>>>> `prerm' or `postrm' scripts require the package to be present in
>>>> order to run. Note, however, that the `postrm' cannot rely on
>>>> any non-essential packages to be present during the `purge'
>>>> phase.
>>> Ack to change s/present/unpacked/g here too.
>> I think this would be somewhat confusing. I know that the statement is
>> strictly logically correct with "unpacked", but it seems as though it
>> would imply to many readers that the package is *only* unpacked, not
>> also configured. In the absence of dependency loops, Depends should
>> guarantee that the depended-upon package is configured rather than
>> merely unpacked while the depending package's postinst runs; I'm not
>> sure about prerm and postrm.
> It's true for the postinst/postrm (except purge) but not for the prerm
> upgrade (AFAIK) and we have recently been bitten by this distinction
> while discussing problems related to the perl 5.10 upgrade.
>> I feel that this may be too fine a distinction to draw in this
>> paragraph without being confusing, and it would be better left
>> non-specific.
> Or maybe we should reword it to be more specific. Ccing Ian Jackson to
> have his input here.
There isn't any further discussion of this in the bug log, and I don't
think there was a reply outside of the bug log. I agree with Colin that
simply changing present to unpacked is potentially confusing, but I would
like to clarify the case for prerm upgrade, and I think it might be worth
drawing the distinction here between what one can normally expect
(configured) and what one may get given circular dependencies.
Does anyone have a specific wording proposal here? I think that's all
that's needed before resolving this bug.
I'll commit the rest of the patch on the bug504880-rra branch.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: