Debian Bug report logs - #504880
Disambiguate "installed" for packages

version graph

Package: debian-policy; Maintainer for debian-policy is Debian Policy List <debian-policy@lists.debian.org>; Source for debian-policy is src:debian-policy.

Reported by: Colin Watson <cjwatson@debian.org>

Date: Fri, 7 Nov 2008 19:15:04 UTC

Owned by: Russ Allbery <rra@debian.org>

Severity: minor

Merged with 403649

Found in versions debian-policy/3.7.2.1, debian-policy/3.8.0.1

Fixed in version debian-policy/3.9.2.0

Done: Russ Allbery <rra@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Fri, 07 Nov 2008 19:15:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
New Bug report received and forwarded. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 07 Nov 2008 19:15:07 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: submit@bugs.debian.org
Subject: Disambiguate "installed" for packages
Date: Fri, 7 Nov 2008 19:13:18 +0000
[Message part 1 (text/plain, inline)]
Package: debian-policy
Version: 3.8.0.1
Severity: wishlist

The policy manual currently uses the word "installed" in a couple of
different ways when referring to packages. Sometimes it's speaking quite
loosely, and in this sense is talking about something roughly equivalent
to 'dpkg --install'. However, in some other cases it's using a sense of
the word which I believe derives from dpkg's internal state machine, and
which corresponds to 'dpkg --unpack'. On quite a number of occasions
I've helped to explain this to people who were confused as a result: for
instance, unless you realise the second sense, the definition of
Conflicts is quite difficult to read.

I suggest that the second sense should be written as "unpacked" rather
than "installed". Although this breaks the correspondence with dpkg's
internal state machine, it brings the policy manual into line with the
verbs used on dpkg's command line, which I think correspond much more
reliably to how people think of the operation or state in question.

I've attached a patch, and am seeking seconds for this proposal. Please
double-check it for correctness, particularly the change in the
definition of Breaks; I have only verified that against an old mail from
Ian proposing the design of this field
(http://lists.debian.org/debian-devel/1997/10/msg00643.html), not
against the current implementation.

Thanks,

-- 
Colin Watson                                       [cjwatson@debian.org]
[policy.unpacked.diff (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Fri, 07 Nov 2008 20:27:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kurt Roeckx <kurt@roeckx.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 07 Nov 2008 20:27:02 GMT) Full text and rfc822 format available.

Message #10 received at submit@bugs.debian.org (full text, mbox):

From: Kurt Roeckx <kurt@roeckx.be>
To: Colin Watson <cjwatson@debian.org>, 504880@bugs.debian.org
Cc: submit@bugs.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Fri, 7 Nov 2008 21:26:05 +0100
On Fri, Nov 07, 2008 at 07:13:18PM +0000, Colin Watson wrote:
> Package: debian-policy
> Version: 3.8.0.1
> Severity: wishlist
> 
> The policy manual currently uses the word "installed" in a couple of
> different ways when referring to packages.

Sometimes it's also using "present" while it probably also means unpacked.  For
instance:
     some packages may
     not be able to rely on their dependencies being present when being
     installed or removed

You also didn't change that installed it seems?

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.


Kurt





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Fri, 07 Nov 2008 20:27:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kurt Roeckx <kurt@roeckx.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 07 Nov 2008 20:27:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Fri, 07 Nov 2008 22:03:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 07 Nov 2008 22:03:07 GMT) Full text and rfc822 format available.

Message #20 received at 504880@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Kurt Roeckx <kurt@roeckx.be>
Cc: 504880@bugs.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Fri, 7 Nov 2008 21:59:56 +0000
On Fri, Nov 07, 2008 at 09:26:05PM +0100, Kurt Roeckx wrote:
> On Fri, Nov 07, 2008 at 07:13:18PM +0000, Colin Watson wrote:
> > The policy manual currently uses the word "installed" in a couple of
> > different ways when referring to packages.
> 
> Sometimes it's also using "present" while it probably also means unpacked.  For
> instance:
>      some packages may
>      not be able to rely on their dependencies being present when being
>      installed or removed
> 
> You also didn't change that installed it seems?

I left some of the vague uses intact when I didn't think they mattered
very much. The uses of "installed" that I left intact by and large refer
to operations that correspond roughly to 'dpkg --install'.

In the case above, I think it could reasonably be replaced with
"installed", but "present" seems OK to me too.

> 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.

Same as above. I don't think this is too confusing in practice, but feel
free to suggest a supplementary diff if you do.

Thanks,

-- 
Colin Watson                                       [cjwatson@debian.org]




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sat, 08 Nov 2008 17:45:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 08 Nov 2008 17:45:07 GMT) Full text and rfc822 format available.

Message #25 received at 504880@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Colin Watson <cjwatson@debian.org>, 504880@bugs.debian.org, Kurt Roeckx <kurt@roeckx.be>
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sat, 8 Nov 2008 18:33:30 +0100
[Message part 1 (text/plain, inline)]
On Fri, 07 Nov 2008, Colin Watson wrote:
> I've attached a patch, and am seeking seconds for this proposal. Please
> double-check it for correctness, particularly the change in the
> definition of Breaks; I have only verified that against an old mail from
> Ian proposing the design of this field
> (http://lists.debian.org/debian-devel/1997/10/msg00643.html), not
> against the current implementation.

Seconded. I agree that it's misleading and ought to be fixed. The part
concerning Breaks looks right from a quick glance in dpkg's source.

On Fri, 07 Nov 2008, Kurt Roeckx wrote:
> Sometimes it's also using "present" while it probably also means unpacked.

I would like to fix those too.

> For instance:
>      some packages may
>      not be able to rely on their dependencies being present when being
>      installed or removed

Ack.

> You also didn't change that installed it seems?

Given that intallation is unpacking + configuration, and that
configuration is mainly running the postinst, and that the
postinst configure can rely on dependencies being unpacked, I think we
should also change installed into unpacked here.

> 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.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sun, 09 Nov 2008 01:09:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 09 Nov 2008 01:09:05 GMT) Full text and rfc822 format available.

Message #30 received at 504880@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 504880@bugs.debian.org, Kurt Roeckx <kurt@roeckx.be>
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 9 Nov 2008 01:08:15 +0000
On Sat, Nov 08, 2008 at 06:33:30PM +0100, Raphael Hertzog wrote:
> On Fri, 07 Nov 2008, Colin Watson wrote:
> > I've attached a patch, and am seeking seconds for this proposal. Please
> > double-check it for correctness, particularly the change in the
> > definition of Breaks; I have only verified that against an old mail from
> > Ian proposing the design of this field
> > (http://lists.debian.org/debian-devel/1997/10/msg00643.html), not
> > against the current implementation.
> 
> Seconded. I agree that it's misleading and ought to be fixed. The part
> concerning Breaks looks right from a quick glance in dpkg's source.

Thanks for the sanity-check.

> On Fri, 07 Nov 2008, Kurt Roeckx wrote:
> > Sometimes it's also using "present" while it probably also means unpacked.
> 
> I would like to fix those too.
> 
> > For instance:
> >      some packages may
> >      not be able to rely on their dependencies being present when being
> >      installed or removed
> 
> Ack.
> 
> > You also didn't change that installed it seems?
> 
> Given that intallation is unpacking + configuration, and that
> configuration is mainly running the postinst, and that the
> postinst configure can rely on dependencies being unpacked, I think we
> should also change installed into unpacked here.

OK, I'm persuaded on this count.

> > 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.

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.

Cheers,

-- 
Colin Watson                                       [cjwatson@debian.org]




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sun, 09 Nov 2008 10:18:26 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 09 Nov 2008 10:18:27 GMT) Full text and rfc822 format available.

Message #35 received at 504880@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Colin Watson <cjwatson@debian.org>
Cc: 504880@bugs.debian.org, Kurt Roeckx <kurt@roeckx.be>, ijackson@chiark.greenend.org.uk
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 9 Nov 2008 10:59:15 +0100
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.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Severity set to `minor' from `wishlist' Request was from Manoj Srivastava <srivasta@golden-gryphon.com> to control@bugs.debian.org. (Thu, 25 Dec 2008 19:03:12 GMT) Full text and rfc822 format available.

Tags added: patch Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Fri, 26 Dec 2008 20:21:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Mon, 02 Feb 2009 05:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 02 Feb 2009 05:18:02 GMT) Full text and rfc822 format available.

Message #44 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 504880@bugs.debian.org, ijackson@chiark.greenend.org.uk
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 01 Feb 2009 21:15:17 -0800
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/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Wed, 11 Feb 2009 10:33:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 11 Feb 2009 10:33:05 GMT) Full text and rfc822 format available.

Message #49 received at 504880@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Russ Allbery <rra@debian.org>, 504880@bugs.debian.org
Cc: Ian Jackson <ian@davenant.greenend.org.uk>
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Wed, 11 Feb 2009 11:31:34 +0100
[Message part 1 (text/plain, inline)]
Hi,

On Sun, 01 Feb 2009, Russ Allbery wrote:
> 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.

The case of circular dependencies is covered a few paragrapth above
the explanation of Depends. I added a small note that tells to check back
but that's all. I detailed the case of each script however.

> Does anyone have a specific wording proposal here?  I think that's all
> that's needed before resolving this bug.

Please find a proposed patch in attachment. Feel free to reword/improve if needed.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
[bug504880-rra.diff (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Wed, 11 Feb 2009 18:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kurt Roeckx <kurt@roeckx.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 11 Feb 2009 18:03:02 GMT) Full text and rfc822 format available.

Message #54 received at 504880@bugs.debian.org (full text, mbox):

From: Kurt Roeckx <kurt@roeckx.be>
To: Raphael Hertzog <hertzog@debian.org>, 504880@bugs.debian.org
Cc: Russ Allbery <rra@debian.org>, Ian Jackson <ian@davenant.greenend.org.uk>
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Wed, 11 Feb 2009 19:00:43 +0100
On Wed, Feb 11, 2009 at 11:31:34AM +0100, Raphael Hertzog wrote:
> diff --git a/policy.sgml b/policy.sgml
> index f5c6818..8727be1 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -4323,10 +4323,17 @@ Build-Depends: foo [!i386] | bar [!amd64]
>  		The <tt>Depends</tt> field should also be used if the
>  		<prgn>postinst</prgn>, <prgn>prerm</prgn> or
>  		<prgn>postrm</prgn> scripts require the package to be
> -		present in order to run.  Note, however, that the
> -		<prgn>postrm</prgn> cannot rely on any non-essential
> -		packages to be present during the <tt>purge</tt>
> -		phase.
> +		present in order to run (if both packages are involved in a
> +                dependency loop, this might not work as expected, see the
> +                explanation a few paragraphs back).  In the case of
> +                <prgn>postinst</prgn> and <prgn>postrm</prgn>, the
> +                depended-on packages will be unpacked and configured.
> +                Note, however, that the <prgn>postrm</prgn> cannot rely on
> +                any non-essential packages to be present during the
> +                <tt>purge</tt> phase.  In the case of <prgn>prerm</prgn>,
> +                the depended-on package will at least be unpacked (it might
> +                be configured too, but you can't rely on it unless you use
> +                <tt>Pre-Depends</tt>).
>  	    </item>
>  
>  	    <tag><tt>Recommends</tt></tag>

This atleast states how I think it works.


Kurt





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Thu, 12 Feb 2009 04:30:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 12 Feb 2009 04:30:02 GMT) Full text and rfc822 format available.

Message #59 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 504880@bugs.debian.org, Ian Jackson <ian@davenant.greenend.org.uk>
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Wed, 11 Feb 2009 20:27:57 -0800
Raphael Hertzog <hertzog@debian.org> writes:

> Please find a proposed patch in attachment. Feel free to reword/improve
> if needed.

Is the reason why you can't rely on configured for the prerm case the same
reason why you can't rely on it for the postinst case: because of breaking
circular dependencies and choosing one package to deconfigure first?  It
just seems conceptually odd to use Pre-Depends for a dependency for a
removal script.

I'm a little concerned that this sounds like an implicit encouragement to
use Pre-Depends more because you can rely on it, and I don't think we want
to do that.  I'm not entirely sure how to avoid that, though, and in
context there are other warnings against using Pre-Depends.  What we
really want to do is actively discourage circular dependencies, since in
the absence of circular dependencies, Depends works as expected and you
can rely on packages being configured for postinst and prerm dependencies.

What happens if there are circular Pre-Depends?  Does dpkg just give up at
that point and throw a fatal error?

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Thu, 12 Feb 2009 07:18:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 12 Feb 2009 07:18:04 GMT) Full text and rfc822 format available.

Message #64 received at 504880@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: 504880@bugs.debian.org, Ian Jackson <ian@davenant.greenend.org.uk>
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Thu, 12 Feb 2009 08:15:09 +0100
On Wed, 11 Feb 2009, Russ Allbery wrote:
> Is the reason why you can't rely on configured for the prerm case the same
> reason why you can't rely on it for the postinst case: because of breaking
> circular dependencies and choosing one package to deconfigure first?  It

No, I believe it's a design choice to be able to unpack all packages in a
first batch and then configure them all in a second one (like apt does).

> I'm a little concerned that this sounds like an implicit encouragement to
> use Pre-Depends more because you can rely on it, and I don't think we want
> to do that.  I'm not entirely sure how to avoid that, though, and in

We don't want that, feel free to reword that part to frighten people that
would like to use it just because that sentence says you can rely on it.
:)

> What happens if there are circular Pre-Depends?  Does dpkg just give up at
> that point and throw a fatal error?

I don't know.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Thu, 12 Feb 2009 09:48:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 12 Feb 2009 09:48:05 GMT) Full text and rfc822 format available.

Message #69 received at 504880@bugs.debian.org (full text, mbox):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Raphael Hertzog <hertzog@debian.org>, 504880@bugs.debian.org
Cc: Ian Jackson <ian@davenant.greenend.org.uk>
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Thu, 12 Feb 2009 10:45:56 +0100
On Wed, Feb 11, 2009 at 08:27:57PM -0800, Russ Allbery wrote:
> Raphael Hertzog <hertzog@debian.org> writes:
> 
> > Please find a proposed patch in attachment. Feel free to reword/improve
> > if needed.
> 
> Is the reason why you can't rely on configured for the prerm case the same
> reason why you can't rely on it for the postinst case: because of breaking
> circular dependencies and choosing one package to deconfigure first?  It
> just seems conceptually odd to use Pre-Depends for a dependency for a
> removal script.
> 
> I'm a little concerned that this sounds like an implicit encouragement to
> use Pre-Depends more because you can rely on it, and I don't think we want
> to do that.  I'm not entirely sure how to avoid that, though, and in
> context there are other warnings against using Pre-Depends.  What we
> really want to do is actively discourage circular dependencies, since in
> the absence of circular dependencies, Depends works as expected and you
> can rely on packages being configured for postinst and prerm dependencies.

I completly agree.

> What happens if there are circular Pre-Depends?  Does dpkg just give up at
> that point and throw a fatal error?

Experimentally, as soon as there is at least one Pre-Depends in a
dependency loop, apt or dpkg throws an error and abort.

Adding Pre-Depends to a circular dependency only make things worse not
better.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sat, 14 Feb 2009 03:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 14 Feb 2009 03:03:02 GMT) Full text and rfc822 format available.

Message #74 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 504880@bugs.debian.org, Ian Jackson <ian@davenant.greenend.org.uk>
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Fri, 13 Feb 2009 18:47:08 -0800
[Message part 1 (text/plain, inline)]
Raphael Hertzog <hertzog@debian.org> writes:

> We don't want that, feel free to reword that part to frighten people
> that would like to use it just because that sentence says you can rely
> on it.  :)

I re-read this whole section while applying your patch and decided that
the wording of the whole section could be improved, so I reworded it in
multiple places.  Could everyone review the following, both for accuracy
and for the recommendations that it makes?  Note that this adds a "should"
requirement that packagers avoid circular dependencies, particularly if a
postinst script is present.

Inline below is just the new part, including a modification of Raphael's
addition.  Attached is the complete patch against the current version of
Policy.

diff --git a/policy.sgml b/policy.sgml
index f5c6818..f4c16ab 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -4273,31 +4273,30 @@ Build-Depends: foo [!i386] | bar [!amd64]
 	</p>
 
 	<p>
-	  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.
-	</p>
-
-        <p>
-          In case of circular dependencies, since installation or
-          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 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
-          all postinst scripts run with the dependencies properly
-          configured if this is possible. Otherwise the breaking point
-          is arbitrary.
-        </p>
-
-	<p>
-	  The <tt>Depends</tt> field thus allows package maintainers
-	  to impose an order in which packages should be configured.
+	  Since <tt>Depends</tt> only places requirements on the
+	  configuration step, packages in an installation run are usually
+	  all unpacked first and all configured later.  This makes it
+	  easier to satisfy all dependencies when multiple packages are
+	  being upgraded.
+	</p>
+
+	<p>
+	  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
+	  <prgn>postinst</prgn> script, then the cycle will be broken at
+	  that package; this ensures that all <prgn>postinst</prgn>
+	  scripts are run with their dependencies properly configured if
+	  this is possible.  Otherwise the breaking point is arbitrary.
+	  Packages should therefore avoid circular dependencies where
+	  possible, particularly if they have <prgn>postinst</prgn>
+	  scripts.
 	</p>
 
 	<p>
@@ -4309,7 +4308,8 @@ Build-Depends: foo [!i386] | bar [!amd64]
 		This declares an absolute dependency.  A package will
 		not be configured unless all of the packages listed in
 		its <tt>Depends</tt> field have been correctly
-		configured.
+		configured (unless there is a circular dependency as
+		described above).
 	      </p>
 
 	      <p>
@@ -4323,10 +4323,17 @@ Build-Depends: foo [!i386] | bar [!amd64]
 		The <tt>Depends</tt> field should also be used if the
 		<prgn>postinst</prgn>, <prgn>prerm</prgn> or
 		<prgn>postrm</prgn> scripts require the package to be
-		present in order to run.  Note, however, that the
-		<prgn>postrm</prgn> cannot rely on any non-essential
-		packages to be present during the <tt>purge</tt>
-		phase.
+		present in order to run.  (If both packages are involved
+		in a dependency loop, this might not work as expected; see
+		the explanation a few paragraphs back.)  In the case of
+		<prgn>postinst</prgn> and <prgn>postrm</prgn>, the
+		depended-on packages will be unpacked and configured
+		first.  (Note, however, that the <prgn>postrm</prgn>
+		cannot rely on any non-essential packages to be present
+		during the <tt>purge</tt> phase.)  In the case of
+		<prgn>prerm</prgn>, the depended-on package will at least
+		be unpacked (it might be configured too, but you can't
+		rely on this unless you use <tt>Pre-Depends</tt>).
 	    </item>
 
 	    <tag><tt>Recommends</tt></tag>
@@ -4389,7 +4396,17 @@ Build-Depends: foo [!i386] | bar [!amd64]
 		to be <em>configured</em>, the pre-dependency will be
 		treated as a normal <tt>Depends</tt>, that is, it will
 		be considered satisfied only if the depended-on
-		package has been correctly configured.
+		package has been correctly configured.  However, unlike
+		with <tt>Depends</tt>, <tt>Pre-Depends</tt> does not
+		permit circular dependencies to be broken.  If a circular
+		dependency is encountered while attempting to honor
+		<tt>Pre-Depends</tt>, the installation will be aborted.
+	      </p>
+
+	      <p>
+		<tt>Pre-Depends</tt> are also required if the
+		<prgn>preinst</prgn> script depends on the named package.
+		It is best to avoid this situation if possible.
 	      </p>
 
 	      <p>
@@ -4398,13 +4415,6 @@ Build-Depends: foo [!i386] | bar [!amd64]
 		installation would hamper the ability of the system to
 		continue with any upgrade that might be in progress.
 	      </p>
-
-	      <p>
-		<tt>Pre-Depends</tt> are also required if the
-		<prgn>preinst</prgn> script depends on the named
-		package.  It is best to avoid this situation if
-		possible.
-	      </p>
 	    </item>
 	  </taglist>
 	</p>


-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


[bug504880-rra (text/plain, attachment)]

Tags added: patch Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Sat, 14 Feb 2009 03:03:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sat, 14 Feb 2009 12:18:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kurt Roeckx <kurt@roeckx.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 14 Feb 2009 12:18:05 GMT) Full text and rfc822 format available.

Message #81 received at 504880@bugs.debian.org (full text, mbox):

From: Kurt Roeckx <kurt@roeckx.be>
To: Russ Allbery <rra@debian.org>, 504880@bugs.debian.org
Cc: Raphael Hertzog <hertzog@debian.org>, Ian Jackson <ian@davenant.greenend.org.uk>
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sat, 14 Feb 2009 13:12:46 +0100
> +	  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.

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.
- 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.
  

Kurt





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sat, 14 Feb 2009 20:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 14 Feb 2009 20:18:02 GMT) Full text and rfc822 format available.

Message #86 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Kurt Roeckx <kurt@roeckx.be>
Cc: 504880@bugs.debian.org, Raphael Hertzog <hertzog@debian.org>, Ian Jackson <ian@davenant.greenend.org.uk>
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sat, 14 Feb 2009 12:16:16 -0800
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/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sat, 14 Feb 2009 20:54:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kurt Roeckx <kurt@roeckx.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 14 Feb 2009 20:54:05 GMT) Full text and rfc822 format available.

Message #91 received at 504880@bugs.debian.org (full text, mbox):

From: Kurt Roeckx <kurt@roeckx.be>
To: Russ Allbery <rra@debian.org>
Cc: 504880@bugs.debian.org, Raphael Hertzog <hertzog@debian.org>, Ian Jackson <ian@davenant.greenend.org.uk>
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sat, 14 Feb 2009 21:50:49 +0100
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





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sat, 14 Feb 2009 21:39:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kurt Roeckx <kurt@roeckx.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 14 Feb 2009 21:39:05 GMT) Full text and rfc822 format available.

Message #96 received at 504880@bugs.debian.org (full text, mbox):

From: Kurt Roeckx <kurt@roeckx.be>
To: Russ Allbery <rra@debian.org>
Cc: 504880@bugs.debian.org, Raphael Hertzog <hertzog@debian.org>, Ian Jackson <ian@davenant.greenend.org.uk>
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sat, 14 Feb 2009 22:38:38 +0100
On Sat, Feb 14, 2009 at 09:50:49PM +0100, Kurt Roeckx wrote:
> On Sat, Feb 14, 2009 at 12:16:16PM -0800, Russ Allbery wrote:
> > 
> > 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.

Policy says that the dependency can be broken at a packages not having
a postinst script.  Which seems to suggest that the other scripts
can be run without problem.  But as far as I know, that's only useful
for the case of installing new packages.

During an new install, or from conffiles only, without errors, unpack does:
- preinst
- unpack

During an upgrade without errors, unpack does:
- old-prerm 
- new-preinst
- unpack
- old-postrm

During remove:
- prerm
- remove files
- postrm

The first case is the only simple case, and requires a Pre-Depends if you
have a preinst script.

For the others you have a problem with the order in which the packages
are processed.


Kurt





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sat, 14 Feb 2009 23:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 14 Feb 2009 23:03:02 GMT) Full text and rfc822 format available.

Message #101 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Kurt Roeckx <kurt@roeckx.be>
Cc: 504880@bugs.debian.org, debian-dpkg@lists.debian.org, Ian Jackson <ian@davenant.greenend.org.uk>
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sat, 14 Feb 2009 15:00:48 -0800
I think at this point we really need someone from the dpkg team to tell us
what Policy needs to be saying here.  This feels like one of those cases
where the best thing to do is just document what dpkg promises to do,
rather than trying to make dpkg match what Policy might be saying.  I'd
like to hammer out in Policy not just what dpkg *does*, but what dpkg
*promises* to do going forward no matter what changes may be made in the
dependency handling (at least without another change to Policy).

I'm copying debian-dpkg towards that end.  See the bottom of this message
after my analysis for my outstanding questions.

Kurt Roeckx <kurt@roeckx.be> writes:
> On Sat, Feb 14, 2009 at 09:50:49PM +0100, Kurt Roeckx wrote:

>>> 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.

If that's the case, then certainly the wording should change back to
unpacked instead of configured.

> Policy says that the dependency can be broken at a packages not having a
> postinst script.  Which seems to suggest that the other scripts can be
> run without problem.  But as far as I know, that's only useful for the
> case of installing new packages.

The current wording does cover the cases of the other scripts.  What my
current proposed wording says, summarized, is:

preinst (all functions):
    Only essential packages or pre-dependencies may be relied on.
    Pre-dependencies will either be configured or will be unpacked or
    half-configured but previously had been configured and was never
    removed.

postinst (all functions):
    All dependencies will be unpacked.  All dependencies will be
    configured provided that there are no dependency cycles.

prerm (all functions):
    All dependencies will be unpacked.  They may or may not be
    configured.

postrm (all functions except purge):
    All dependencies will be configured.  (Given that prerm doesn't
    require that they be configured, this is odd -- Raphael, can you
    confirm this is really what you intended?)

postrm purge:
    Only essential packages may be relied on.

Walking through the possible ways that the scripts are called:

preinst install
preinst upgrade
    The normal cases, for which the wording above should be fine.

preinst abort-upgrade
    This is called when a package is being upgraded, the old postrm fails
    an upgrade action, and the new postrm also fails a failed-upgrade
    action.  The wording above should still be fine at this point.  The
    package is unpacked, but that doesn't imply that dependencies will be
    available.

postinst configure
    The normal case, for which the above wording should be fine.

postinst abort-upgrade
    Called for the currently installed package when the old prerm upgrade
    script fails and the new prerm failed-upgrade script also fails, or
    when the preinst of the new package fails (in which case it's called
    first in the new package and then in the old package).  This is done
    before unpacking the new package.  It can also be called after
    unpacking the new package if postrm upgrade fails, I believe after
    unwinding the attempted package installation.  I think this is a case
    where dependencies may not be satisfied in the case that the new
    version of the package and the old version of the package have
    contradictory dependencies.

postinst abort-remove
    Called when the prerm script for a package fails.  I think the above
    language should be correct for this, since even if the package is
    being removed due to conflicts, I would expect that to happen in
    advance of the new packages being unpacked.  But I'm not sure.

postinst abort-deconfigure
    Called only when prerm deconfigure fails, which in turn is called only
    when packages are removed due to Breaks or because they depended on a
    conflicting package that's being removed.  As with abort-remove, I'm
    not sure if such work is always done in advance of unpacking packages
    that may break dependencies.

prerm remove
    The normal case.  The above language should be fine.

prerm upgrade
    This is the first thing that's called during the unpack of an upgrade,
    before anything else.  As with abort-remove and abort-deconfigure,
    whether one can rely on dependencies being unpacked depends on whether
    this is done before unpacking all the possible dependencies.

prerm failed-upgrade
    This is a special case: it's an error handler for a prerm upgrade
    failure in the previous version of the package.  If dependencies would
    be unpacked for prerm upgrade, they wouldn't be unpacked for prerm
    failed-upgrade, and vice versa.  So we definitely don't guarantee that
    all dependencies are unpacked for all prerm functions.

prerm deconfigure
    Called when packages are removed due to Breaks or because they
    depended on a conflicting package that's being removed.  As above,
    depends on the ordering during an upgrade.

postrm remove
    The regular removal case, for which the above language should be
    correct.

postrm purge
    Only essential packages are guaranteed, as discussed.

postrm upgrade
    Called after the new package is unpacked, so fairly definitely can't
    rely on its dependencies being unpacked if they conflict with the
    dependencies of the new version.

postrm failed-upgrade
    As with prerm failed-upgrade, this is a special case error handler for
    a failed postrm upgrade in the previous version.  In this case, it's
    called after the package is unpacked but before it's configured, so
    probably can't rely on its dependencies being configured.

postrm abort-install
    Called if preinst install fails.  This can probably only rely on
    having the same things that preinst has.

postrm abort-upgrade
    Called during the nastiest error handling case, where the old postrm
    upgrade and the new postrm failed-upgrade both fail after the unpack.
    It's called in the new package after the old preinst abort-upgrade
    succeeds.  I'm not sure what the package can rely on at this point.

postrm disappear
    Called if all of your files have gone away after unpacking a new
    package.  I'm fairly sure that the above language is correct for this
    and you can rely on all dependencies being present, since otherwise it
    would hit one of the other cases of removal due to conflicts.

So... what does that all mean we should say?  Unfortunately, it looks like
a mess, and not just for the circular dependency case.  Even without
circular dependencies, we can end up with weird conditions if the
dependencies of a new package are mutually incompatible with the
dependencies of the old version of the package.  We also don't know
whether one can rely on all of one's dependencies being unpacked when
postinst configure is called, or if they might not even be unpacked.

What I'd like at this point are answers from the dpkg developers about
dpkg's behavior in the following areas:

1. Are all package dependencies guaranteed to at least be unpacked at the
   time that postinst configure is called, even if there are circular
   dependencies?

2. Is a package guaranteed that its dependencies will still at least be
   unpacked when its prerm upgrade is called, even if the new package
   we're in the process of installing has dependencies that cannot be
   satisfied at the same time as the dependencies of the currently
   installed package?

3. The same question as (2) for prerm deconfigure.

If the answer to all of the above questions is yes, then I think we can
say that package dependencies are always at least unpacked when postinst
configure, prerm remove, and prerm deconfigure are called, and package
dependencies are always configured when postrm remove and postrm disappear
are called.  Package dependencies are also always configured when postinst
configure is called unless there are circular dependencies.  Then I would
just say that there are no guarantees for the other postinst, prerm, and
postrm actions.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sun, 15 Feb 2009 17:12:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 15 Feb 2009 17:12:02 GMT) Full text and rfc822 format available.

Message #106 received at 504880@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: Russ Allbery <rra@debian.org>
Cc: Kurt Roeckx <kurt@roeckx.be>, 504880@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 15 Feb 2009 17:10:28 +0000
Russ Allbery writes ("Re: Bug#504880: Disambiguate "installed" for packages"):
> The current wording does cover the cases of the other scripts.  What my
> current proposed wording says, summarized, is:
...

This is a very helpful way of presenting it.

> postrm (all functions except purge):
>     All dependencies will be configured.  (Given that prerm doesn't
>     require that they be configured, this is odd -- Raphael, can you
>     confirm this is really what you intended?)

I don't think this is right.

postrm in principle can be run without the dependencies even
installed.  For example, the dependencies might have been removed
after the package was deconfigured (ie, put into state `unpacked') but
before it was removed.

So postrm cannot make any more assumptions than preinst.  (Also postrm
is sometimes used to undo preinst.)

> postrm purge:
>     Only essential packages may be relied on.

So I think this is always true of postrm.

> prerm (all functions):
>     All dependencies will be unpacked.  They may or may not be
>     configured.
...
> postinst abort-upgrade
> postinst abort-remove
> postinst abort-deconfigure

I don't think you have analysed this quite correctly.

The key point is that unpacking a package is not considered to break
dependencies.  Ie, if  A -Depends-> B  and both are `installed', dpkg
will allow a new version of B to be unpacked (thus moving B from
`installed' through various even-worse states to `unpacked').  This is
not regarded as requring A to be deconfigured.

Thus the criterion for A being `installed' is not that B is also
`installed', but rather that B was `installed' at some previous point
and has not been removed (or replaced with an inappropriate version)
since.

But the prerm is only called if the package was originally in state
`installed' or `half-installed', which means that this condition is
satisfied whenever the prerm is called.

So in summary:
 * while it's true that the dependencies may not be configured,
   they will have been configured more recently than they were
   removed (indeed this is the same condition as for Pre-Depends)
 * the depencies might be in a worse state than `unpacked'; they
   might be in `half-installed' due to an upgrade unpack which
   had previously failed (dpkg tries to avoid this situation but
   it can occur); in principle the on-disk files might even be
   a mixture from the two versions of the dependency, although
   dpkg tries hard to avoid this

postinst abort-* are error-unwinding cases for the prerm.  Thus they
may be called in any situation when the prerm may be called.

> What I'd like at this point are answers from the dpkg developers about
> dpkg's behavior in the following areas:
> 
> 1. Are all package dependencies guaranteed to at least be unpacked at the
>    time that postinst configure is called, even if there are circular
>    dependencies?

Yes.

> 2. Is a package guaranteed that its dependencies will still at least be
>    unpacked when its prerm upgrade is called, even if the new package
>    we're in the process of installing has dependencies that cannot be
>    satisfied at the same time as the dependencies of the currently
>    installed package?

Yes.  The new version's dependencies are irrelevant, just as the
dependencies are irrelevant for the unpack of a
not-previously-installed package.

> 3. The same question as (2) for prerm deconfigure.

Yes.

During any call to the prerm, all dependencies are satisfied at least
as much as they would be for the preinst if they were Pre-Depends.

This is not done explicitly by checking in the code, but is a
consequence of the other restrictions, which ensure that the prerm
will be called before that dependency condition is broken.

> If the answer to all of the above questions is yes, then I think we can
> say that package dependencies are always at least unpacked when postinst
> configure, prerm remove, and prerm deconfigure are called,

Yes.

>  and package dependencies are always configured when postrm remove
> and postrm disappear are called.

No, the postrm is not entitled to assume anything very much.

>   Package dependencies are also always configured when postinst
> configure is called unless there are circular dependencies.  Then I would
> just say that there are no guarantees for the other postinst, prerm, and
> postrm actions.

The postinst abort-* activities work the same way as prerm.

Ian.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Fri, 05 Jun 2009 19:30:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Frank Küster <frank@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 05 Jun 2009 19:30:02 GMT) Full text and rfc822 format available.

Message #111 received at 504880@bugs.debian.org (full text, mbox):

From: Frank Küster <frank@debian.org>
To: debian-devel <debian-devel@lists.debian.org>
Cc: Debian TeX maintainers <debian-tex-maint@lists.debian.org>, 504880@bugs.debian.org, 530832@bugs.debian.org, ia64@buildd.debian.org,
Subject: Re: Bug#531581: Critical problems on hppa and ia64 buildds
Date: Fri, 05 Jun 2009 21:29:23 +0200
retitle 530832 maintainer scripts created by tex-common may not assume tex-common to be present in "postrm remove"
thanks

ia64, I assume that you have moved the broken remains of texlive-base
away manually?

Agustin Martin <agmartin@debian.org> wrote:

> Frank, your package honours current Debian policy about that, but Debian
> Policy is buggy about that.

Thank you very much. You seem to be the first person who's not yelling
but giving arguments.

> See #504880, message #106 from Ian Jackson. You cannot rely on dependencies
> being installed at postrm,
>
> Imagine package a depends on package b
>
> # dpkg --unpack a
> # dpkg --purge  a
>
> can be done without "b" present. And you do not need any --force option.

Yes, I see.

We'll have to make an upload of texlive-2007.

Regards, Frank
-- 
Dr. Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Fri, 05 Jun 2009 20:21:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Luk Claes <luk@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 05 Jun 2009 20:21:02 GMT) Full text and rfc822 format available.

Message #116 received at 504880@bugs.debian.org (full text, mbox):

From: Luk Claes <luk@debian.org>
To: Frank Küster <frank@debian.org>
Cc: debian-devel <debian-devel@lists.debian.org>, Debian TeX maintainers <debian-tex-maint@lists.debian.org>, 504880@bugs.debian.org, 530832@bugs.debian.org, ia64@buildd.debian.org
Subject: Re: Bug#531581: Critical problems on hppa and ia64 buildds
Date: Fri, 05 Jun 2009 22:24:26 +0200
Frank Küster wrote:
> retitle 530832 maintainer scripts created by tex-common may not assume tex-common to be present in "postrm remove"
> thanks
> 
> ia64, I assume that you have moved the broken remains of texlive-base
> away manually?

He's called Lamont btw... oh right, that's the bugsubmitter all along...

> Agustin Martin <agmartin@debian.org> wrote:
> 
>> Frank, your package honours current Debian policy about that, but Debian
>> Policy is buggy about that.
> 
> Thank you very much. You seem to be the first person who's not yelling
> but giving arguments.

Only because you seem to need a whole argumentation...

Cheers

Luk




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sat, 06 Jun 2009 11:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Norbert Preining <preining@logic.at>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 06 Jun 2009 11:27:03 GMT) Full text and rfc822 format available.

Message #121 received at 504880@bugs.debian.org (full text, mbox):

From: Norbert Preining <preining@logic.at>
To: debian-devel <debian-devel@lists.debian.org>, Debian TeX maintainers <debian-tex-maint@lists.debian.org>, Frank Küster <frank@debian.org>, Luk Claes <luk@debian.org>
Cc: 504880@bugs.debian.org, 530832@bugs.debian.org, ia64@buildd.debian.org
Subject: Re: Bug#531581: Critical problems on hppa and ia64 buildds
Date: Sat, 6 Jun 2009 13:14:18 +0200
Hi guys,

let's calm down, its now worth discussing this even further. Policy is
buggy, we try to work around it.

> We'll have to make an upload of texlive-2007.

First we need a fixed tex-common that creates "proper" (for buggy
policy) postrm code.

Then we can bump build-dep of texlive to that version of tex-common and
rebuild.

Questions: Do we want to bring that into lenny? I vote for NO, to much
changes in tex-common already done (triggers).

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining <preining@logic.at>        Vienna University of Technology
Debian Developer <preining@debian.org>                         Debian TeX Group
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
SWANAGE (pl.n.)
Swanage is the series of diversionary tactics used when trying to
cover up the existence of a glossop (q.v.) and may include (a)
uttering a high-pitched laugh and pointing out of the window (NB. this
doesn't work more that twice); (b) sneezing as loudly as possible and
wiping the glossop off the table in the same movement as whipping out
your handkerchief; (c) saying 'Christ! I seen to have dropped some
shit on your table' (very unwise); (d) saying 'Christ, who did that?'
(better) (e) pressing your elbow on the glossop itself and working
your arms slowly to the edge of the table; (f) leaving the glossop
where it is but moving a plate over it and putting up with sitting at
an uncomfortable angle the rest of the meal; or, if the glossop is in
too exposed a position, (g) leaving it there unremarked except for the
occasional humorous glance.
			--- Douglas Adams, The Meaning of Liff




Removed tag(s) patch. Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Fri, 04 Jun 2010 06:39:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Tue, 20 Jul 2010 18:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 20 Jul 2010 18:30:03 GMT) Full text and rfc822 format available.

Message #128 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Colin Watson <cjwatson@debian.org>
Cc: 504880@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Tue, 20 Jul 2010 11:26:20 -0700
Colin Watson <cjwatson@debian.org> writes:

> The policy manual currently uses the word "installed" in a couple of
> different ways when referring to packages. Sometimes it's speaking quite
> loosely, and in this sense is talking about something roughly equivalent
> to 'dpkg --install'. However, in some other cases it's using a sense of
> the word which I believe derives from dpkg's internal state machine, and
> which corresponds to 'dpkg --unpack'. On quite a number of occasions
> I've helped to explain this to people who were confused as a result: for
> instance, unless you realise the second sense, the definition of
> Conflicts is quite difficult to read.

> I suggest that the second sense should be written as "unpacked" rather
> than "installed". Although this breaks the correspondence with dpkg's
> internal state machine, it brings the policy manual into line with the
> verbs used on dpkg's command line, which I think correspond much more
> reliably to how people think of the operation or state in question.

This bug and its corresponding patch have grown rather far beyond Colin's
intention, since we uncovered a lot of other issues during the discussion
around exactly what dependency scripts can assume.  I finally had a chance
to read over Ian Jackson's reply in detail and try to incorporate it into
this patch.  Here is the result.

This adds new information to the "Summary of ways maintainer scripts are
called" section (6.5) stating exactly what maintainer scripts can depend
on when various actions are called.  Since we worked that out over the
course of the discussion, I don't want to lose that information, since
that's been opaque to me for years and would greatly benefit from being
documented.

This patch also, based on Ian's analysis, makes clear that postrm cannot
rely on dependencies being available even for cases other than purge and
is more explicit in several cases about what dependencies do for you.  It
has a new "should" discouraging circular dependencies.

Please review in detail, as this is the first documentation we'll have of
several hairy assumptions involved in maintainer script dependencies.

diff --git a/policy.sgml b/policy.sgml
index 847f716..7fc9ad1 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1079,8 +1079,8 @@
 	</p>
 
 	<p>
-	  Sometimes, a package requires another package to be installed
-	  <em>and</em> configured before it can be installed. In this
+	  Sometimes, a package requires another package to be unpacked
+	  <em>and</em> configured before it can be unpacked. In this
 	  case, you must specify a <tt>Pre-Depends</tt> entry for
 	  the package.
 	</p>
@@ -3674,7 +3674,7 @@ Checksums-Sha256:
 
 	<p>
 	  Broadly speaking the <prgn>preinst</prgn> is called before
-	  (a particular version of) a package is installed, and the
+	  (a particular version of) a package is unpacked, and the
 	  <prgn>postinst</prgn> afterwards; the <prgn>prerm</prgn>
 	  before (a version of) a package is removed and the
 	  <prgn>postrm</prgn> afterwards.
@@ -3758,111 +3758,166 @@ Checksums-Sha256:
 	</heading>
 
 	<p>
-	  <list compact="compact">
-	    <item>
-	      <var>new-preinst</var> <tt>install</tt>
-	    </item>
-	    <item>
-	      <var>new-preinst</var> <tt>install</tt> <var>old-version</var>
-	    </item>
-	    <item>
-		<var>new-preinst</var> <tt>upgrade</tt> <var>old-version</var>
-	    </item>
-	    <item>
-		<var>old-preinst</var> <tt>abort-upgrade</tt>
-		<var>new-version</var>
-	    </item>
-	  </list>
+	  What follows is a summary of all the ways in which maintainer
+	  scripts may be called along with what facilities those scripts
+	  may rely on being available at that time.  Script names
+	  preceeded by <var>new-</var> are the scripts from the new
+	  version of a package being installed or upgraded.  Script names
+	  preceeded by <var>old-</var> are the scripts from the old
+	  version of a package that is being upgraded to a new version.
+	</p>
 
 	<p>
-	  <list compact="compact">
-	    <item>
-		<var>postinst</var> <tt>configure</tt>
-		<var>most-recently-configured-version</var>
-	    </item>
-	    <item>
-		<var>old-postinst</var> <tt>abort-upgrade</tt>
-		<var>new-version</var>
-	    </item>
-	    <item>
-		<var>conflictor's-postinst</var> <tt>abort-remove</tt>
-		<tt>in-favour</tt> <var>package</var>
-		<var>new-version</var>
-	    </item>
+	  The <prgn>preinst</prgn> script may be called in the following
+	  ways:
+	  <taglist>
+	    <tag><var>new-preinst</var> <tt>install</tt></tag>
+	    <tag><var>new-preinst</var> <tt>install</tt>
+	      <var>old-version</var></tag>
+	    <tag><var>new-preinst</var> <tt>upgrade</tt>
+	      <var>old-version</var></tag>
 	    <item>
-		<var>postinst</var> <tt>abort-remove</tt>
+	      Only essential packages and pre-dependencies
+	      (<tt>Pre-Depends</tt>) may be assumed to be available.
+	      Pre-dependencies will either be configured or will be
+	      "Unpacked" or "Half-Configured" but previously had been
+	      configured and was never removed.  The package will not yet
+	      be unpacked, so the <prgn>preinst</prgn> script cannot rely
+	      on any files included in its package.
 	    </item>
+
+	    <tag><var>old-preinst</var> <tt>abort-upgrade</tt>
+	      <var>new-version</var></tag>
 	    <item>
-		<var>deconfigured's-postinst</var>
-		<tt>abort-deconfigure</tt> <tt>in-favour</tt>
-		<var>failed-install-package</var> <var>version</var>
-		[<tt>removing</tt> <var>conflicting-package</var>
-		<var>version</var>]
+	      Called during error handling of an upgrade that failed after
+	      unpacking the new package because the
+	      old <prgn>postrm</prgn> failed during the upgrade action.
+	      Depending on the severity and nature of the error, the
+	      package's dependencies, including pre-dependencies, may be
+	      only "Half-Installed" or "Unpacked" and are not necessarily
+	      configured, and the files for the old package may not yet be
+	      unpacked.
 	    </item>
-	  </list>
+	  </taglist>
+	</p>
 
 	<p>
-	  <list compact="compact">
-	    <item>
-		<var>prerm</var> <tt>remove</tt>
-	    </item>
-	    <item>
-		<var>old-prerm</var> <tt>upgrade</tt>
-		<var>new-version</var>
-	    </item>
-	    <item>
-		<var>new-prerm</var> <tt>failed-upgrade</tt>
-		<var>old-version</var>
-	    </item>
+	  The <prgn>postinst</prgn> script may be called in the following
+	  ways:
+	  <taglist>
+	    <tag><var>postinst</var> <tt>configure</tt>
+	      <var>most-recently-configured-version</var></tag>
 	    <item>
-		<var>conflictor's-prerm</var> <tt>remove</tt>
-		<tt>in-favour</tt> <var>package</var>
-		<var>new-version</var>
+	      The files contained in the package will be unpacked.  All
+	      package dependencies will at least be unpacked.  If there
+	      are no circular dependencies involved, all package
+	      dependencies will be configured.
 	    </item>
+
+	    <tag><var>old-postinst</var> <tt>abort-upgrade</tt>
+	      <var>new-version</var></tag>
+	    <tag><var>conflictor's-postinst</var> <tt>abort-remove</tt>
+	      <tt>in-favour</tt> <var>package</var>
+	      <var>new-version</var></tag>
+	    <tag><var>postinst</var> <tt>abort-remove</tt></tag>
+	    <tag><var>deconfigured's-postinst</var>
+	      <tt>abort-deconfigure</tt> <tt>in-favour</tt>
+	      <var>failed-install-package</var> <var>version</var>
+	      [<tt>removing</tt> <var>conflicting-package</var>
+	      <var>version</var>]</tag>
 	    <item>
-		<var>deconfigured's-prerm</var> <tt>deconfigure</tt>
-		<tt>in-favour</tt> <var>package-being-installed</var>
-		<var>version</var> [<tt>removing</tt>
-		<var>conflicting-package</var>
-		<var>version</var>]
+	      The files contained in the package will be unpacked.  All
+	      package dependencies will at least be "Half-Installed" and
+	      will have previously been configured and not removed.
+	      However, depending on the nature and severity of the error,
+	      dependencies may not be configured or even fully unpacked.
 	    </item>
-	  </list>
+	  </taglist>
+	</p>
 
 	<p>
-	  <list compact="compact">
-	    <item>
-		<var>postrm</var> <tt>remove</tt>
-	    </item>
-	    <item>
-		<var>postrm</var> <tt>purge</tt>
-	    </item>
-	    <item>
-		<var>old-postrm</var> <tt>upgrade</tt>
-		<var>new-version</var>
-	    </item>
+	  The <prgn>prerm</prgn> script may be called in the following
+	  ways:
+	  <taglist>
+	    <tag><var>prerm</var> <tt>remove</tt></tag>
+	    <tag><var>old-prerm</var>
+	      <tt>upgrade</tt><var>new-version</var></tag>
+	    <tag><var>conflictor's-prerm</var> <tt>remove</tt>
+	      <tt>in-favour</tt> <var>package</var>
+	      <var>new-version</var></tag>
+	    <tag><var>deconfigured's-prerm</var> <tt>deconfigure</tt>
+	      <tt>in-favour</tt> <var>package-being-installed</var>
+	      <var>version</var> [<tt>removing</tt>
+	      <var>conflicting-package</var> <var>version</var>]</tag>
 	    <item>
-		<var>new-postrm</var> <tt>failed-upgrade</tt>
-		<var>old-version</var>
+	      The package whose <prgn>prerm</prgn> is being called will be
+	      at least "Half-Installed".  All package dependencies will at
+	      least be "Half-Installed" and will have previously been
+	      configured and not removed.  If there was no error, all
+	      dependencies will at least be unpacked, but these actions
+	      may be called in various error states where dependencies are
+	      only "Half-Installed".
 	    </item>
+
+	    <tag><var>new-prerm</var> <tt>failed-upgrade</tt>
+	      <var>old-version</var></tag>
 	    <item>
-		<var>new-postrm</var> <tt>abort-install</tt>
+	      Called during error handling when <tt>prerm upgrade</tt>
+	      fails.  The new package will not yet be unpacked.  Since
+	      this is the first action taken during a package upgrade,
+	      only essential packages and pre-dependencies may be relied
+	      on.  Pre-dependencies will either be configured or will be
+	      "Unpacked" or "Half-Configured" but previously had been
+	      configured and was never removed.
 	    </item>
+	  </taglist>
+	</p>
+
+	<p>
+	  The <prgn>postrm</prgn> script may be called in the following
+	  ways:
+	  <taglist>
+	    <tag><var>postrm</var> <tt>remove</tt></tag>
+	    <tag><var>postrm</var> <tt>purge</tt></tag>
+	    <tag><var>old-postrm</var> <tt>upgrade</tt>
+	      <var>new-version</var></tag>
+	    <tag><var>disappearer's-postrm</var> <tt>disappear</tt>
+		<var>overwriter</var> <var>overwriter-version</var></tag>
 	    <item>
-		<var>new-postrm</var> <tt>abort-install</tt>
-		<var>old-version</var>
+	      The <prgn>postrm</prgn> script is called after the package's
+	      files have been removed.  The package
+	      whose <prgn>postrm</prgn> is being called may have
+	      previously been deconfigured and only be unpacked, at which
+	      point subsequent package changes do not consider its
+	      dependencies.  Therefore, all <prgn>postrm</prgn> actions
+	      may only rely on essential packages and cannot assume that
+	      the package's dependencies are available.
 	    </item>
+
+	    <tag><var>new-postrm</var> <tt>failed-upgrade</tt>
+	      <var>old-version</var></tag>
 	    <item>
-		<var>new-postrm</var> <tt>abort-upgrade</tt>
-		<var>old-version</var>
+	      Called when the old <tt>postrm upgrade</tt> action fails.
+	      The new package will be unpacked, but only essential
+	      packages and pre-dependencies can be relied on.
+	      Pre-dependencies will either be configured or will be
+	      "Unpacked" or "Half-Configured" but previously had been
+	      configured and was never removed.
 	    </item>
+
+	    <tag><var>new-postrm</var> <tt>abort-install</tt></tag>
+	    <tag><var>new-postrm</var> <tt>abort-install</tt>
+	      <var>old-version</var></tag>
+	    <tag><var>new-postrm</var> <tt>abort-upgrade</tt>
+	      <var>old-version</var></tag>
 	    <item>
-		<var>disappearer's-postrm</var> <tt>disappear</tt>
-		<var>overwriter</var>
-		<var>overwriter-version</var>
+	      Called before unpackaging the new package as part of the
+	      error handling of <prgn>preinst</prgn> failures.  May assume
+	      the same state as <prgn>preinst</prgn> can assume.
 	    </item>
-	  </list>
+	  </taglist>
 	</p>
-
+      </sect>
 
       <sect id="unpackphase">
 	<heading>Details of unpack phase of installation or upgrade</heading>
@@ -4064,7 +4119,7 @@ Checksums-Sha256:
 		behavior which, though deterministic, is hard for the
 		system administrator to understand.  It can easily
 		lead to "missing" programs if, for example, a package
-		is installed which overwrites a file from another
+		is unpacked which overwrites a file from another
 		package, and is then removed again.<footnote>
 		    Part of the problem is due to what is arguably a
 		    bug in <prgn>dpkg</prgn>.
@@ -4200,7 +4255,7 @@ Checksums-Sha256:
 		If there was a conflicting package we go and do the
 		removal actions (described below), starting with the
 		removal of the conflicting package's files (any that
-		are also in the package being installed have already
+		are also in the package being unpacked have already
 		been removed from the conflicting package's file list,
 		and so do not get removed now).
 	    </item>
@@ -4540,31 +4595,29 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	</p>
 
 	<p>
-	  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.
+	  Since <tt>Depends</tt> only places requirements on the
+	  configuration step, packages in an installation run are usually
+	  all unpacked first and all configured later.  This makes it
+	  easier to satisfy all dependencies when multiple packages are
+	  being upgraded.
 	</p>
 
-        <p>
-          In case of circular dependencies, since installation or
-          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
-          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
-          all postinst scripts run with the dependencies properly
-          configured if this is possible. Otherwise the breaking point
-          is arbitrary.
-        </p>
-
 	<p>
-	  The <tt>Depends</tt> field thus allows package maintainers
-	  to impose an order in which packages should be configured.
+	  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 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 <prgn>postinst</prgn>
+	  script, then the cycle will be broken at that package; this
+	  ensures that all <prgn>postinst</prgn> scripts are run with
+	  their dependencies properly configured if this is possible.
+	  Otherwise the breaking point is arbitrary.  Packages should
+	  therefore avoid circular dependencies where possible,
+	  particularly if they have <prgn>postinst</prgn> scripts.
 	</p>
 
 	<p>
@@ -4576,7 +4629,8 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 		This declares an absolute dependency.  A package will
 		not be configured unless all of the packages listed in
 		its <tt>Depends</tt> field have been correctly
-		configured.
+		configured (unless there is a circular dependency as
+		described above).
 	      </p>
 
 	      <p>
@@ -4588,12 +4642,16 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 
 	      <p>
 		The <tt>Depends</tt> field should also be used if the
-		<prgn>postinst</prgn>, <prgn>prerm</prgn> or
-		<prgn>postrm</prgn> scripts require the package to be
-		present in order to run.  Note, however, that the
-		<prgn>postrm</prgn> cannot rely on any non-essential
-		packages to be present during the <tt>purge</tt>
-		phase.
+		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
+		require the package to be unpacked or configured in order
+		to run.  In the case of <prgn>postinst</prgn>, the
+		depended-on packages will be unpacked and configured
+		first.  (If both packages are involved in a dependency
+		loop, this might not work as expected; see the explanation
+		a few paragraphs back.)  In the case
+		of <prgn>prerm</prgn>, the package dependencies will be at
+		least unpacked or "Half-Installed".
+	      </p>
 	    </item>
 
 	    <tag><tt>Recommends</tt></tag>
@@ -4652,11 +4710,21 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	      </p>
 
 	      <p>
-		When the package declaring a pre-dependency is about
-		to be <em>configured</em>, the pre-dependency will be
-		treated as a normal <tt>Depends</tt>, that is, it will
-		be considered satisfied only if the depended-on
-		package has been correctly configured.
+		When the package declaring a pre-dependency is about to
+		be <em>configured</em>, the pre-dependency will be treated
+		as a normal <tt>Depends</tt>.  It will be considered
+		satisfied only if the depended-on package has been
+		correctly configured.  However, unlike
+		with <tt>Depends</tt>, <tt>Pre-Depends</tt> does not
+		permit circular dependencies to be broken.  If a circular
+		dependency is encountered while attempting to honor
+		<tt>Pre-Depends</tt>, the installation will be aborted.
+	      </p>
+
+	      <p>
+		<tt>Pre-Depends</tt> are also required if the
+		<prgn>preinst</prgn> script depends on the named package.
+		It is best to avoid this situation if possible.
 	      </p>
 
 	      <p>
@@ -4665,13 +4733,6 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 		installation would hamper the ability of the system to
 		continue with any upgrade that might be in progress.
 	      </p>
-
-	      <p>
-		<tt>Pre-Depends</tt> are also required if the
-		<prgn>preinst</prgn> script depends on the named
-		package.  It is best to avoid this situation if
-		possible.
-	      </p>
 	    </item>
 	  </taglist>
 	</p>
@@ -4696,7 +4757,7 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	<p>
 	  When one binary package declares that it breaks another,
 	  <prgn>dpkg</prgn> will refuse to allow the package which
-	  declares <tt>Breaks</tt> be installed unless the broken
+	  declares <tt>Breaks</tt> be unpacked unless the broken
 	  package is deconfigured first, and it will refuse to
 	  allow the broken package to be reconfigured.
 	</p>
@@ -4749,7 +4810,7 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	<p>
           When one binary package declares a conflict with another
 	  using a <tt>Conflicts</tt> field, <prgn>dpkg</prgn> will
-	  refuse to allow them to be installed on the system at the
+	  refuse to allow them to be unpacked on the system at the
 	  same time.  This is a stronger restriction than <tt>Breaks</tt>,
 	  which just prevents both packages from being configured at the
 	  same time.  Conflicting packages cannot be unpacked on the
@@ -4757,8 +4818,8 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	</p>
 
 	<p>
-	  If one package is to be installed, the other must be removed
-	  first.  If the package being installed is marked as replacing
+	  If one package is to be unpacked, the other must be removed
+	  first.  If the package being unpacked is marked as replacing
 	  (see <ref id="replaces">, but note that <tt>Breaks</tt> should
 	  normally be used in this case) the one on the system, or the one
 	  on the system is marked as deselected, or both packages are
@@ -5039,7 +5100,7 @@ Provides: mail-transport-agent
 Conflicts: mail-transport-agent
 Replaces: mail-transport-agent
 	    </example>
-	    ensuring that only one MTA can be installed at any one
+	    ensuring that only one MTA can be unpacked at any one
 	    time.  See <ref id="virtual"> for more information about this
 	    example.
 	</sect1>
@@ -5338,7 +5399,7 @@ Replaces: mail-transport-agent
          <footnote>
 	    <p>
 	      During install or upgrade, the preinst is called before
-	      the new files are installed, so calling "ldconfig" is
+	      the new files are unpacked, so calling "ldconfig" is
 	      pointless.  The preinst of an existing package can also be
 	      called if an upgrade fails.  However, this happens during
 	      the critical time when a shared libs may exist on-disk
@@ -5483,7 +5544,7 @@ Replaces: mail-transport-agent
 	<ref id="conflicts">) to ensure that the user only installs one
 	development version at a time (as different development versions are
 	likely to have the same header files in them, which would cause a
-	filename clash if both were installed).
+	filename clash if both were unpacked).
       </p>
 
       <p>
@@ -9774,7 +9835,7 @@ END-INFO-DIR-ENTRY
 	<p>
 	  The <prgn>DEBIAN</prgn> directory will not appear in the
 	  file system archive of the package, and so won't be installed
-	  by <prgn>dpkg</prgn> when the package is installed.
+	  by <prgn>dpkg</prgn> when the package is unpacked.
 	</p>
 
 	<p>

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Added tag(s) patch. Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Tue, 20 Jul 2010 18:30:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Tue, 20 Jul 2010 22:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 20 Jul 2010 22:39:03 GMT) Full text and rfc822 format available.

Message #135 received at 504880@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: Colin Watson <cjwatson@debian.org>, 504880@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Tue, 20 Jul 2010 17:35:40 -0500
Hi,

Russ Allbery wrote:

> This adds new information to the "Summary of ways maintainer scripts are
> called" section (6.5) stating exactly what maintainer scripts can depend
> on when various actions are called.

This is very welcome.  Thanks for moving it forward.

Warning: most of what I say below is with reference to the old version
of policy, not the dpkg source.  So please check with someone more
reliable before taking anything I say as a given.

> +++ b/policy.sgml
> @@ -3758,111 +3758,166 @@ Checksums-Sha256:
>  	</heading>
>  
>  	<p>
> +	  What follows is a summary of all the ways in which maintainer
> +	  scripts may be called along with what facilities those scripts
> +	  may rely on being available at that time.  Script names
> +	  preceeded by <var>new-</var> are the scripts from the new
> +	  version of a package being installed or upgraded.  Script names
> +	  preceeded by <var>old-</var> are the scripts from the old
> +	  version of a package that is being upgraded to a new version.
> +	</p>

Spelling: “preceeded” should be “preceded”.

The term “upgraded” is a bit ambiguous in situations where a package is
being downgraded or an upgrade is being rolled back.  Probably the
context makes the meaning obvious in any particular instance, though.

> +
> +	<p>
> +	  The <prgn>preinst</prgn> script may be called in the following
> +	  ways:
> -	  <list compact="compact">
> -	    <item>
> -	      <var>new-preinst</var> <tt>install</tt>
> -	    </item>
> -	    <item>
> -	      <var>new-preinst</var> <tt>install</tt> <var>old-version</var>
> -	    </item>
> -	    <item>
> -		<var>new-preinst</var> <tt>upgrade</tt> <var>old-version</var>
> -	    </item>
> +	  <taglist>
> +	    <tag><var>new-preinst</var> <tt>install</tt></tag>
> +	    <tag><var>new-preinst</var> <tt>install</tt>
> +	      <var>old-version</var></tag>
> +	    <tag><var>new-preinst</var> <tt>upgrade</tt>
> +	      <var>old-version</var></tag>
> +	    <item>
> +	      Only essential packages and pre-dependencies
> +	      (<tt>Pre-Depends</tt>) may be assumed to be available.
> +	      Pre-dependencies will either be configured or will be
> +	      "Unpacked" or "Half-Configured" but previously had been
> +	      configured and was never removed.

The second sentence is starting to get wordy.  Maybe:

	Only essential packages and pre-dependencies
	(<tt>Pre-Depends</tt>) may be assumed to be available.
	Pre-dependencies will be unpacked and have been
	configured after they were last removed[1].

	[1] During an upgrade, a package listed in
	<tt>Pre-Depends</tt> may be "Unpacked" or "Half-Configured"
	in its new version, but only if a previous version was
	configured completely and the package has not been
	removed since then.

I doubt these rules apply to the initial bootstrap.  Is that worth
mentioning somewhere?

>                                                The package will not yet
> +	      be unpacked, so the <prgn>preinst</prgn> script cannot rely
> +	      on any files included in its package.
> +	    </item>
> +
> -	    <item>
> -		<var>old-preinst</var> <tt>abort-upgrade</tt>
> -		<var>new-version</var>
> -	    </item>
> -	  </list>
> -
> +	    <tag><var>old-preinst</var> <tt>abort-upgrade</tt>
> +	      <var>new-version</var></tag>
> +	    <item>
> +	      Called during error handling of an upgrade that failed after
> +	      unpacking the new package because the
> +	      old <prgn>postrm</prgn> failed during the upgrade action.

Getting wordy.  Maybe:

	Called to recover from an upgrade that failed after
	unpacking the new package because the old <prgn>postrm</prgn>
	failed.

> +	      Depending on the severity and nature of the error, the
> +	      package's dependencies, including pre-dependencies, may be
> +	      only "Half-Installed" or "Unpacked" and are not necessarily
> +	      configured, and the files for the old package may not yet be
> +	      unpacked.
> +	    </item>
> +	  </taglist>
> +	</p>

 * Not sure what the phrase “Depending on the ... nature of the
   error” is supposed to be getting at here.  Is this just to say
   the package might not have been fully installed yet?  I would
   leave the clause out.

 * Can’t (new) dependencies be missing altogether?  I thought part of
   the point of the pre-depends/depends distinction was that the
   latter does not constrain unpacking order.

 * Could old (removed) dependencies be missing altogether, too?
   Sure: if I unpack one version of the package and then try to
   unpack the next and that fails, ...

 * postrm does not get called until pre-dependencies for the new
   version are satisfied.  So I think it is impossible for
   pre-dependencies to be half-installed here.

 * As usual in the halfinstalled state, files from both the
   new and the old package may be missing.

So:

	Pre-dependencies for the old and new versions of the package
	will be at least unpacked and have been configured after they
	were last removed[1].

	The package's dependencies (<tt>Depends</tt>) in the new and
	old versions are not guaranteed to be satisfied, and files
	from the old and new versions of the package are neither
	guaranteed to be present nor not present in the file system.

In particular, it is not so pleasant to imagine, but given:

 packagea, version 1: Pre-Depends: packageb
 packagea, version 2: Pre-Depends: packagec
 packagec: Conflicts: packageb

I think frontends/dpkg will correctly error out.

Another edge case involves replaces (packagec could make packageb
disappear), but that is a topic for another day.

> -	<p>
> -	  <list compact="compact">
> -	    <item>
> -		<var>postinst</var> <tt>configure</tt>
> -		<var>most-recently-configured-version</var>
> -	    </item>
> +
> +	<p>
> +	  The <prgn>postinst</prgn> script may be called in the following
> +	  ways:
> +	  <taglist>
> +	    <tag><var>postinst</var> <tt>configure</tt>
> +	      <var>most-recently-configured-version</var></tag>
> +	    <item>
> +	      The files contained in the package will be unpacked.  All
> +	      package dependencies will at least be unpacked.  If there
> +	      are no circular dependencies involved, all package
> +	      dependencies will be configured.
> +	    </item>

Nice.

[...]
> +	    <tag><var>old-postinst</var> <tt>abort-upgrade</tt>
> +	      <var>new-version</var></tag>
> +	    <tag><var>conflictor's-postinst</var> <tt>abort-remove</tt>
> +	      <tt>in-favour</tt> <var>package</var>
> +	      <var>new-version</var></tag>
> +	    <tag><var>postinst</var> <tt>abort-remove</tt></tag>
> +	    <tag><var>deconfigured's-postinst</var>
> +	      <tt>abort-deconfigure</tt> <tt>in-favour</tt>
> +	      <var>failed-install-package</var> <var>version</var>
> +	      [<tt>removing</tt> <var>conflicting-package</var>
> +	      <var>version</var>]</tag>
> +	    <item>
> +	      The files contained in the package will be unpacked.  All
> +	      package dependencies will at least be "Half-Installed" and
> +	      will have previously been configured and not removed.
> +	      However, depending on the nature and severity of the error,
> +	      dependencies may not be configured or even fully unpacked.
> +	    </item>
> +	  </taglist>
> +	</p>

An example of when dependencies can be half-installed would be
helpful.

For example, where packagea depends on packageb:

	dpkg --install packagea_1.deb packageb_1.deb

	dpkg --unpack packageb_2.deb
	^C; # now packageb is halfinstalled

	dpkg --remove packagea

Now if prerm fails, then postinst abort-remove will be called
with packageb halfinstalled.

Notice:

 * Dependencies are always checked when dpkg --configure (or
   dpkg --install) is run for a package without --force-depends.
   The only interesting cases are:

    - aborting a removal
    - aborting an upgrade in which a dependency has been dropped

 * If I understand correctly, postinst can rely on Depends satisfying
   the same condition as Pre-Depends usually do: _some_ version
   of the dependent package was once fully installed, and the package
   has not been removed since then.

[...]
> +	  <taglist>
> +	    <tag><var>prerm</var> <tt>remove</tt></tag>
> +	    <tag><var>old-prerm</var>
> +	      <tt>upgrade</tt><var>new-version</var></tag>
> +	    <tag><var>conflictor's-prerm</var> <tt>remove</tt>
> +	      <tt>in-favour</tt> <var>package</var>
> +	      <var>new-version</var></tag>
> +	    <tag><var>deconfigured's-prerm</var> <tt>deconfigure</tt>
> +	      <tt>in-favour</tt> <var>package-being-installed</var>
> +	      <var>version</var> [<tt>removing</tt>
> +	      <var>conflicting-package</var> <var>version</var>]</tag>
> +	    <item>
> +	      The package whose <prgn>prerm</prgn> is being called will be
> +	      at least "Half-Installed".  All package dependencies will at
> +	      least be "Half-Installed" and will have previously been
> +	      configured and not removed.  If there was no error, all
> +	      dependencies will at least be unpacked, but these actions
> +	      may be called in various error states where dependencies are
> +	      only "Half-Installed".
> +	    </item>
> +

Any package we call prerm for is halfconfigured or better, so all
of its dependencies were fully satisfied at some point.

Like before, it is probably worth mentioning that dependencies can
only be halfinstalled in this case due to a partial upgrade, not a
partial install.

> +	    <tag><var>new-prerm</var> <tt>failed-upgrade</tt>
> +	      <var>old-version</var></tag>
> +	    <item>
> +	      Called during error handling when <tt>prerm upgrade</tt>
> +	      fails.  The new package will not yet be unpacked.  Since
> +	      this is the first action taken during a package upgrade,
> +	      only essential packages and pre-dependencies may be relied
> +	      on.  Pre-dependencies will either be configured or will be
> +	      "Unpacked" or "Half-Configured" but previously had been
> +	      configured and was never removed.
> +	    </item>
> +	  </taglist>
> +	</p>

Why can’t one rely on dependencies here, too?

[...]
> -	    <item>
> -		<var>old-postrm</var> <tt>upgrade</tt>
> -		<var>new-version</var>
> -	    </item>
> +
> +	<p>
> +	  The <prgn>postrm</prgn> script may be called in the following
> +	  ways:
> +	  <taglist>
> +	    <tag><var>postrm</var> <tt>remove</tt></tag>
> +	    <tag><var>postrm</var> <tt>purge</tt></tag>
> +	    <tag><var>old-postrm</var> <tt>upgrade</tt>
> +	      <var>new-version</var></tag>
> +	    <tag><var>disappearer's-postrm</var> <tt>disappear</tt>
> +		<var>overwriter</var> <var>overwriter-version</var></tag>
> +	    <item>
> +	      The <prgn>postrm</prgn> script is called after the package's
> +	      files have been removed.  The package
> +	      whose <prgn>postrm</prgn> is being called may have
> +	      previously been deconfigured and only be unpacked, at which
> +	      point subsequent package changes do not consider its
> +	      dependencies.  Therefore, all <prgn>postrm</prgn> actions
> +	      may only rely on essential packages and cannot assume that
> +	      the package's dependencies are available.
> +	    </item>

Yes.

For upgrade, the new package will be unpacked already, right?  Maybe
that should be discussed in the same paragraph as failed-upgrade.

[...]
> -	    <item>
> -		<var>new-postrm</var> <tt>abort-install</tt>
> -	    </item>
> -	    <item>
> -		<var>new-postrm</var> <tt>abort-install</tt>
> -		<var>old-version</var>
> -	    </item>
> -	    <item>
> -		<var>new-postrm</var> <tt>abort-upgrade</tt>
> -		<var>old-version</var>
> -	    </item>
> -	    <item>
> -		<var>disappearer's-postrm</var> <tt>disappear</tt>
> -		<var>overwriter</var>
> -		<var>overwriter-version</var>
> -	    </item>
> -	  </list>
> +
> +	    <tag><var>new-postrm</var> <tt>abort-install</tt></tag>
> +	    <tag><var>new-postrm</var> <tt>abort-install</tt>
> +	      <var>old-version</var></tag>
> +	    <tag><var>new-postrm</var> <tt>abort-upgrade</tt>
> +	      <var>old-version</var></tag>
> +	    <item>
> +	      Called before unpackaging the new package as part of the
> +	      error handling of <prgn>preinst</prgn> failures.  May assume
> +	      the same state as <prgn>preinst</prgn> can assume.
> +	    </item>
> +	  </taglist>
>  	</p>
> -
> +      </sect>

Looks good.

Stopping here.  Will pick up with the rest in a separate message.
Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Wed, 21 Jul 2010 00:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 21 Jul 2010 00:03:04 GMT) Full text and rfc822 format available.

Message #140 received at 504880@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: Colin Watson <cjwatson@debian.org>, 504880@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Tue, 20 Jul 2010 18:59:05 -0500
Hi again,

Continuing where I left off.

>        <sect id="unpackphase">
>  	<heading>Details of unpack phase of installation or upgrade</heading>
[...]
> @@ -4540,31 +4595,29 @@       <chapt id="relationships">
>  	</p>
>  
>  	<p>
> -	  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.
> +	  Since <tt>Depends</tt> only places requirements on the
> +	  configuration step, packages in an installation run are usually
> +	  all unpacked first and all configured later.  This makes it
> +	  easier to satisfy all dependencies when multiple packages are
> +	  being upgraded.
>  	</p>

The new second sentence is less specific than the anthropomorphizing
original.  Intended?

[...]
> -	  The <tt>Depends</tt> field thus allows package maintainers
> -	  to impose an order in which packages should be configured.
>  	</p>

Is this removal intended?

[...]
> @@ -4588,12 +4642,16 @@     <sect id="binarydeps">
>  
>  	      <p>
>  		The <tt>Depends</tt> field should also be used if the
> -		<prgn>postinst</prgn>, <prgn>prerm</prgn> or
> -		<prgn>postrm</prgn> scripts require the package to be
> -		present in order to run.  Note, however, that the
> -		<prgn>postrm</prgn> cannot rely on any non-essential
> -		packages to be present during the <tt>purge</tt>
> -		phase.
> +		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
> +		require the package to be unpacked or configured in order
> +		to run.

Huh?

postinst in the normal case requires the package being installed to be
unpacked and all its dependencies to be configured.  prerm requires
the package being removed to be halfconfigured.

I think part of my confusion is because:

 * this item is supposed to be about what the Depends field can
   be used to accomplish, not what requirements postinst and
   preinst have;

 * before, “the package” meant the package depended on, but now
   it means the package being installed or removed.

>		         In the case of <prgn>postinst</prgn>, the
> +		depended-on packages will be unpacked and configured
> +		first.  (If both packages are involved in a dependency
> +		loop, this might not work as expected; see the explanation
> +		a few paragraphs back.)  In the case
> +		of <prgn>prerm</prgn>, the package dependencies will be at
> +		least unpacked or "Half-Installed".
> +	      </p>

So maybe something roughly like

	<p>
	  The <tt>Depends</tt> field should also be used if the
	  <prgn>postinst</prgn> or <prgn>prerm</prgn> scripts require
	  the package to be present in order to run.  See the descriptions
	  of postinst and prem in section 6.5 for details.[1]
	</p>

	[1] In the case of <prgn>postinst</prgn> <tt>configure</tt>,
	the depended-on packages will be unpacked and configured
	before the script is run.  When <prgn>postinst</prgn> or
	<prgn>prerm</prgn> is called for some other reason, the
	depended-on packages will have been unpacked and fully
	configured at some point since they were last removed, but
	they may have been deconfigured since then or even left
	"Half-Installed" after a partial upgrade.

would be less confusing.

> @@ -4652,11 +4710,21 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
>  	      </p>
>  
>  	      <p>
> -		When the package declaring a pre-dependency is about
> -		to be <em>configured</em>, the pre-dependency will be
> -		treated as a normal <tt>Depends</tt>, that is, it will
> -		be considered satisfied only if the depended-on
> -		package has been correctly configured.
> +		When the package declaring a pre-dependency is about to
> +		be <em>configured</em>, the pre-dependency will be treated
> +		as a normal <tt>Depends</tt>.  It will be considered
> +		satisfied only if the depended-on package has been
> +		correctly configured.  However, unlike
> +		with <tt>Depends</tt>, <tt>Pre-Depends</tt> does not
> +		permit circular dependencies to be broken.  If a circular
> +		dependency is encountered while attempting to honor
> +		<tt>Pre-Depends</tt>, the installation will be aborted.
> +	      </p>

Nice.

> +
> +	      <p>
> +		<tt>Pre-Depends</tt> are also required if the
> +		<prgn>preinst</prgn> script depends on the named package.
> +		It is best to avoid this situation if possible.
>  	      </p>

This moves the instruction to above the warning, so the final
paragraph can emphasize that Pre-Depends should be avoided.
Makes sense.

> @@ -4696,7 +4757,7 @@     <sect id="breaks">
>  	<p>
>  	  When one binary package declares that it breaks another,
>  	  <prgn>dpkg</prgn> will refuse to allow the package which
> -	  declares <tt>Breaks</tt> be installed unless the broken
> +	  declares <tt>Breaks</tt> be unpacked unless the broken
>  	  package is deconfigured first

Oh!  That’s true, and a very useful clarification.

>	                               , and it will refuse to
>  	  allow the broken package to be reconfigured.
>  	</p>
> @@ -4749,7 +4810,7 @@     <sect id="conflicts">
>  	<p>
>            When one binary package declares a conflict with another
>  	  using a <tt>Conflicts</tt> field, <prgn>dpkg</prgn> will
> -	  refuse to allow them to be installed on the system at the
> +	  refuse to allow them to be unpacked on the system at the
>  	  same time.  This is a stronger restriction than <tt>Breaks</tt>,
>  	  which just prevents both packages from being configured at the
>  	  same time.  Conflicting packages cannot be unpacked on the

Whoops.

	      This is a stronger restriction than <tt>Breaks</tt>,
	which only prevents the broken package from being configured at
	the same time as the breaking package is unpacked.

> @@ -4757,8 +4818,8 @@     <sect id="conflicts">
>  	</p>
>  
>  	<p>
> -	  If one package is to be installed, the other must be removed
> -	  first.  If the package being installed is marked as replacing
> +	  If one package is to be unpacked, the other must be removed
> +	  first.  If the package being unpacked is marked as replacing
>  	  (see <ref id="replaces">, but note that <tt>Breaks</tt> should
>  	  normally be used in this case) the one on the system, or the one
>  	  on the system is marked as deselected, or both packages are

Yep.

With whatever subset of the above changes seems appropriate, this
looks good to me.

Regards,
Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Wed, 21 Jul 2010 20:27:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 21 Jul 2010 20:27:06 GMT) Full text and rfc822 format available.

Message #145 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Wed, 21 Jul 2010 13:24:54 -0700
Thank you very much for the detailed review!

Jonathan Nieder <jrnieder@gmail.com> writes:
> Russ Allbery wrote:

>>  	<p>
>> +	  What follows is a summary of all the ways in which maintainer
>> +	  scripts may be called along with what facilities those scripts
>> +	  may rely on being available at that time.  Script names
>> +	  preceeded by <var>new-</var> are the scripts from the new
>> +	  version of a package being installed or upgraded.  Script names
>> +	  preceeded by <var>old-</var> are the scripts from the old
>> +	  version of a package that is being upgraded to a new version.
>> +	</p>

> Spelling: “preceeded” should be “preceded”.

Fixed.

> The term “upgraded” is a bit ambiguous in situations where a package is
> being downgraded or an upgrade is being rolled back.  Probably the
> context makes the meaning obvious in any particular instance, though.

I now have:

	<p>
	  What follows is a summary of all the ways in which maintainer
	  scripts may be called along with what facilities those scripts
	  may rely on being available at that time.  Script names preceded
	  by <var>new-</var> are the scripts from the new version of a
	  package being installed, upgraded to, or downgraded to.  Script
	  names preceded by <var>old-</var> are the scripts from the old
	  version of a package that is being upgraded from or downgraded
	  from.
	</p>

to mention downgrades.  The meaning of new and old of course doesn't
change even during error unwind, but hopefully that's still clear from
context.

>> +	      Only essential packages and pre-dependencies
>> +	      (<tt>Pre-Depends</tt>) may be assumed to be available.
>> +	      Pre-dependencies will either be configured or will be
>> +	      "Unpacked" or "Half-Configured" but previously had been
>> +	      configured and was never removed.

> The second sentence is starting to get wordy.  Maybe:

> 	Only essential packages and pre-dependencies
> 	(<tt>Pre-Depends</tt>) may be assumed to be available.
> 	Pre-dependencies will be unpacked and have been
> 	configured after they were last removed[1].

> 	[1] During an upgrade, a package listed in
> 	<tt>Pre-Depends</tt> may be "Unpacked" or "Half-Configured"
> 	in its new version, but only if a previous version was
> 	configured completely and the package has not been
> 	removed since then.

I don't want to move state information into a footnote.  Here's a new
version that is hopefully a bit cleaner:

	    <item>
	      The package will not yet be unpacked, so
	      the <prgn>preinst</prgn> script cannot rely on any files
	      included in its package.  Only essential packages and
	      pre-dependencies (<tt>Pre-Depends</tt>) may be assumed to be
	      available.  Pre-dependencies will be at least unpacked.
	      They may be only unpacked or "Half-Configured", not
	      completely configured, but only if a previous version of the
	      pre-dependency was completely configured and the
	      pre-dependency had not been removed since then.
	    </item>

> I doubt these rules apply to the initial bootstrap.  Is that worth
> mentioning somewhere?

I don't think so.  Initial bootstrap, like udebs, feels to me like
something that's outside the intended scope of Policy.

>> +	      Called during error handling of an upgrade that failed after
>> +	      unpacking the new package because the
>> +	      old <prgn>postrm</prgn> failed during the upgrade action.

> Getting wordy.  Maybe:

> 	Called to recover from an upgrade that failed after
> 	unpacking the new package because the old <prgn>postrm</prgn>
> 	failed.

The point that I'm trying to get at here is that it's specifically postrm
upgrade that failed.  I reworded it some -- see below.

>> +	      Depending on the severity and nature of the error, the
>> +	      package's dependencies, including pre-dependencies, may be
>> +	      only "Half-Installed" or "Unpacked" and are not necessarily
>> +	      configured, and the files for the old package may not yet be
>> +	      unpacked.

>  * Not sure what the phrase “Depending on the ... nature of the
>    error” is supposed to be getting at here.  Is this just to say
>    the package might not have been fully installed yet?  I would
>    leave the clause out.

Reworded to leave that out.

>  * Can’t (new) dependencies be missing altogether?  I thought part of
>    the point of the pre-depends/depends distinction was that the
>    latter does not constrain unpacking order.

I believe unpacking order is still constrained, but the unpacked packages
don't have to be fully configured before the depending package is
unpacked.  With Pre-Depends, the dependency is fully configured before the
depending package is unpacked.

However, you're right, I don't think anything guarantees that the
dependencies are available at this point, only the pre-dependencies.

>  * postrm does not get called until pre-dependencies for the new
>    version are satisfied.  So I think it is impossible for
>    pre-dependencies to be half-installed here.

I believe, from what Ian said, that it's possible if the pre-dependencies
of the old version are different than the pre-dependencies of the new
version and the upgrade of the pre-dependencies failed.

> So:

> 	Pre-dependencies for the old and new versions of the package
> 	will be at least unpacked and have been configured after they
> 	were last removed[1].

> 	The package's dependencies (<tt>Depends</tt>) in the new and
> 	old versions are not guaranteed to be satisfied, and files
> 	from the old and new versions of the package are neither
> 	guaranteed to be present nor not present in the file system.

What I have now, given the above, is:

	    <item>
	      Called during error handling of an upgrade that failed after
	      unpacking the new package because the <tt>postrm
	      upgrade</tt> action failed.  The unpacked files may be
	      partly from the new version or partly missing, so the script
	      cannot not rely on files included in the package.  Package
	      dependencies may not be available.  Pre-dependencies will be
	      at least unpacked following the same rules as above, except
	      they may be only "Half-Installed" if an upgrade of the
	      pre-dependency failed.
	    </item>

>> +	    <item>
>> +	      The files contained in the package will be unpacked.  All
>> +	      package dependencies will at least be "Half-Installed" and
>> +	      will have previously been configured and not removed.
>> +	      However, depending on the nature and severity of the error,
>> +	      dependencies may not be configured or even fully unpacked.
>> +	    </item>
>> +	  </taglist>
>> +	</p>

> An example of when dependencies can be half-installed would be
> helpful.

I now have:

	    <item>
	      The files contained in the package will be unpacked.  All
	      package dependencies will at least be "Half-Installed" and
	      will have previously been configured and not removed.
	      However, dependencies may not be configured or even fully
	      unpacked in some error situations.<footnote>
		For example, suppose packages foo and bar are installed
		with foo depending on bar.  If an upgrade of bar were
		started and then aborted, and then an attempt to remove
		foo failed because its <prgn>prerm</prgn> script failed,
		foo's <tt>postinst abort-remove</tt> would be called with
		bar only "Half-Installed".
	      </footnote>
	    </item>

>> +	    <item>
>> +	      The package whose <prgn>prerm</prgn> is being called will be
>> +	      at least "Half-Installed".  All package dependencies will at
>> +	      least be "Half-Installed" and will have previously been
>> +	      configured and not removed.  If there was no error, all
>> +	      dependencies will at least be unpacked, but these actions
>> +	      may be called in various error states where dependencies are
>> +	      only "Half-Installed".
>> +	    </item>
>> +

> Any package we call prerm for is halfconfigured or better, so all
> of its dependencies were fully satisfied at some point.

Right, that's the point of the second sentence.

> Like before, it is probably worth mentioning that dependencies can
> only be halfinstalled in this case due to a partial upgrade, not a
> partial install.

Added a note to that effect.

>> +	    <tag><var>new-prerm</var> <tt>failed-upgrade</tt>
>> +	      <var>old-version</var></tag>
>> +	    <item>
>> +	      Called during error handling when <tt>prerm upgrade</tt>
>> +	      fails.  The new package will not yet be unpacked.  Since
>> +	      this is the first action taken during a package upgrade,
>> +	      only essential packages and pre-dependencies may be relied
>> +	      on.  Pre-dependencies will either be configured or will be
>> +	      "Unpacked" or "Half-Configured" but previously had been
>> +	      configured and was never removed.
>> +	    </item>

> Why can’t one rely on dependencies here, too?

Look at when prerm failed-upgrade is called.  If one is upgrading package
foo to a newer version, the very first thing that happens, long before the
new package is unpacked, is that the old prerm script is called with an
argument of upgrade.  If this fails, the preinst script for the new
package is called with the argument failed-upgrade.  Since this is early
in the unpack stage, there are no guarantees about unpack order.

If prerm failed-upgrade could rely on dependencies being unpacked, so
could preinst, since preinst is called later in the process.  The
situation for prerm failed-upgrade is identical to the situation for
preinst.  I think I'll just say this:

	    <item>
	      Called during error handling when <tt>prerm upgrade</tt>
	      fails.  The new package will not yet be unpacked, and all
	      the same constraints as for <tt>preinst upgrade</tt> apply.
	    </item>

>> +	    <item>
>> +	      The <prgn>postrm</prgn> script is called after the package's
>> +	      files have been removed.  The package
>> +	      whose <prgn>postrm</prgn> is being called may have
>> +	      previously been deconfigured and only be unpacked, at which
>> +	      point subsequent package changes do not consider its
>> +	      dependencies.  Therefore, all <prgn>postrm</prgn> actions
>> +	      may only rely on essential packages and cannot assume that
>> +	      the package's dependencies are available.
>> +	    </item>

> Yes.

> For upgrade, the new package will be unpacked already, right?  Maybe
> that should be discussed in the same paragraph as failed-upgrade.

I'm hesitant to do so since it may lead people to assume that files or
dependencies are available since they would be provided by the new
version, without realizing that they can't anticipate what the new version
of the package may do and the new version may have completely different
files and dependencies.

The right rule here is to not rely on anything other than essential
packages.

I did add "or replaced" at the end of the first sentence there.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Wed, 21 Jul 2010 20:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 21 Jul 2010 20:39:03 GMT) Full text and rfc822 format available.

Message #150 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Wed, 21 Jul 2010 13:37:28 -0700
Jonathan Nieder <jrnieder@gmail.com> writes:

>>  	<p>
>> -	  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.
>> +	  Since <tt>Depends</tt> only places requirements on the
>> +	  configuration step, packages in an installation run are usually
>> +	  all unpacked first and all configured later.  This makes it
>> +	  easier to satisfy all dependencies when multiple packages are
>> +	  being upgraded.
>>  	</p>

> The new second sentence is less specific than the anthropomorphizing
> original.  Intended?

I found the original awkward and hard to puzzle out.  How about this:

	<p>
	  Since <tt>Depends</tt> only places requirements on the order in
	  which packages are configured, packages in an installation run
	  are usually all unpacked first and all configured later.  This
	  allows multiple packages to be upgraded in one unpack and
	  configure step even if some packages being upgraded have
	  versioned dependencies on the upgraded versions of other
	  packages involved in the installation run.
	</p>

which hopefully re-adds the specific information.

> [...]
>> -	  The <tt>Depends</tt> field thus allows package maintainers
>> -	  to impose an order in which packages should be configured.
>>  	</p>

> Is this removal intended?

Yes, it seems to just duplicate the first sentence of the paragraph above
and the description of Depends later on.

> [...]
>> @@ -4588,12 +4642,16 @@     <sect id="binarydeps">
>>  
>>  	      <p>
>>  		The <tt>Depends</tt> field should also be used if the
>> -		<prgn>postinst</prgn>, <prgn>prerm</prgn> or
>> -		<prgn>postrm</prgn> scripts require the package to be
>> -		present in order to run.  Note, however, that the
>> -		<prgn>postrm</prgn> cannot rely on any non-essential
>> -		packages to be present during the <tt>purge</tt>
>> -		phase.
>> +		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
>> +		require the package to be unpacked or configured in order
>> +		to run.

> Huh?

> postinst in the normal case requires the package being installed to be
> unpacked and all its dependencies to be configured.  prerm requires the
> package being removed to be halfconfigured.

> I think part of my confusion is because:

>  * this item is supposed to be about what the Depends field can
>    be used to accomplish, not what requirements postinst and
>    preinst have;

>  * before, “the package” meant the package depended on, but now
>    it means the package being installed or removed.

I think you're completely misreading the new paragraph.  I added another
"depended-on" to the wording to hopefully make it clearer.  How's this,
which also addresses the fact that the rules are different for postinst
configure than for the other cases?

	      <p>
		The <tt>Depends</tt> field should also be used if the
		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
		require the depended-on package to be unpacked or
		configured in order to run.  In the case of <tt>postinst
		configure</tt>, the depended-on packages will be unpacked
		and configured first.  (If both packages are involved in a
		dependency loop, this might not work as expected; see the
		explanation a few paragraphs back.)  In the case
		of <prgn>prerm</prgn> or other <prgn>postinst</prgn>
		actions, the package dependencies will be at least
		unpacked or "Half-Installed".
	      </p>


>>  	<p>
>>            When one binary package declares a conflict with another
>>  	  using a <tt>Conflicts</tt> field, <prgn>dpkg</prgn> will
>> -	  refuse to allow them to be installed on the system at the
>> +	  refuse to allow them to be unpacked on the system at the
>>  	  same time.  This is a stronger restriction than <tt>Breaks</tt>,
>>  	  which just prevents both packages from being configured at the
>>  	  same time.  Conflicting packages cannot be unpacked on the

> Whoops.

> 	      This is a stronger restriction than <tt>Breaks</tt>,
> 	which only prevents the broken package from being configured at
> 	the same time as the breaking package is unpacked.

I believe what I wrote is more correct than what you wrote.  What do you
think is wrong about it which prompts the "whoops"?  Breaks allows both
packages to be unpacked at the same time, but only one of the two packages
can be configured at the same time.  Configuring one package will result
in deconfiguring the other.  (At least.  I think under normal
circumstances the broken package is then removed, although I'm not sure
since Policy never says that.  All Policy says will happen is that it will
be deconfigured.)

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Wed, 21 Jul 2010 20:57:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 21 Jul 2010 20:57:05 GMT) Full text and rfc822 format available.

Message #155 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 504880@bugs.debian.org
Cc: Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Wed, 21 Jul 2010 13:52:50 -0700
Russ Allbery <rra@debian.org> writes:

> Please review in detail, as this is the first documentation we'll have
> of several hairy assumptions involved in maintainer script dependencies.

Here is an updated patch reflecting feedback from Ben Finney and Jonathan
Nieder.

diff --git a/policy.sgml b/policy.sgml
index 847f716..eb458fe 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1079,10 +1079,10 @@
 	</p>
 
 	<p>
-	  Sometimes, a package requires another package to be installed
-	  <em>and</em> configured before it can be installed. In this
-	  case, you must specify a <tt>Pre-Depends</tt> entry for
-	  the package.
+	  Sometimes, a package requires another package to be unpacked
+	  <em>and</em> configured before it can be unpacked.  In this
+	  case, the dependent package must specify this dependency in
+	  the <tt>Pre-Depends</tt> control field.
 	</p>
 
 	<p>
@@ -3674,7 +3674,7 @@ Checksums-Sha256:
 
 	<p>
 	  Broadly speaking the <prgn>preinst</prgn> is called before
-	  (a particular version of) a package is installed, and the
+	  (a particular version of) a package is unpacked, and the
 	  <prgn>postinst</prgn> afterwards; the <prgn>prerm</prgn>
 	  before (a version of) a package is removed and the
 	  <prgn>postrm</prgn> afterwards.
@@ -3758,111 +3758,173 @@ Checksums-Sha256:
 	</heading>
 
 	<p>
-	  <list compact="compact">
-	    <item>
-	      <var>new-preinst</var> <tt>install</tt>
-	    </item>
-	    <item>
-	      <var>new-preinst</var> <tt>install</tt> <var>old-version</var>
-	    </item>
-	    <item>
-		<var>new-preinst</var> <tt>upgrade</tt> <var>old-version</var>
-	    </item>
-	    <item>
-		<var>old-preinst</var> <tt>abort-upgrade</tt>
-		<var>new-version</var>
-	    </item>
-	  </list>
+	  What follows is a summary of all the ways in which maintainer
+	  scripts may be called along with what facilities those scripts
+	  may rely on being available at that time.  Script names preceded
+	  by <var>new-</var> are the scripts from the new version of a
+	  package being installed, upgraded to, or downgraded to.  Script
+	  names preceded by <var>old-</var> are the scripts from the old
+	  version of a package that is being upgraded from or downgraded
+	  from.
+	</p>
 
 	<p>
-	  <list compact="compact">
-	    <item>
-		<var>postinst</var> <tt>configure</tt>
-		<var>most-recently-configured-version</var>
-	    </item>
-	    <item>
-		<var>old-postinst</var> <tt>abort-upgrade</tt>
-		<var>new-version</var>
-	    </item>
-	    <item>
-		<var>conflictor's-postinst</var> <tt>abort-remove</tt>
-		<tt>in-favour</tt> <var>package</var>
-		<var>new-version</var>
-	    </item>
+	  The <prgn>preinst</prgn> script may be called in the following
+	  ways:
+	  <taglist>
+	    <tag><var>new-preinst</var> <tt>install</tt></tag>
+	    <tag><var>new-preinst</var> <tt>install</tt>
+	      <var>old-version</var></tag>
+	    <tag><var>new-preinst</var> <tt>upgrade</tt>
+	      <var>old-version</var></tag>
 	    <item>
-		<var>postinst</var> <tt>abort-remove</tt>
+	      The package will not yet be unpacked, so
+	      the <prgn>preinst</prgn> script cannot rely on any files
+	      included in its package.  Only essential packages and
+	      pre-dependencies (<tt>Pre-Depends</tt>) may be assumed to be
+	      available.  Pre-dependencies will be at least unpacked.
+	      They may be only unpacked or "Half-Configured", not
+	      completely configured, but only if a previous version of the
+	      pre-dependency was completely configured and the
+	      pre-dependency had not been removed since then.
 	    </item>
+
+	    <tag><var>old-preinst</var> <tt>abort-upgrade</tt>
+	      <var>new-version</var></tag>
 	    <item>
-		<var>deconfigured's-postinst</var>
-		<tt>abort-deconfigure</tt> <tt>in-favour</tt>
-		<var>failed-install-package</var> <var>version</var>
-		[<tt>removing</tt> <var>conflicting-package</var>
-		<var>version</var>]
+	      Called during error handling of an upgrade that failed after
+	      unpacking the new package because the <tt>postrm
+	      upgrade</tt> action failed.  The unpacked files may be
+	      partly from the new version or partly missing, so the script
+	      cannot not rely on files included in the package.  Package
+	      dependencies may not be available.  Pre-dependencies will be
+	      at least unpacked following the same rules as above, except
+	      they may be only "Half-Installed" if an upgrade of the
+	      pre-dependency failed.
 	    </item>
-	  </list>
+	  </taglist>
+	</p>
 
 	<p>
-	  <list compact="compact">
-	    <item>
-		<var>prerm</var> <tt>remove</tt>
-	    </item>
-	    <item>
-		<var>old-prerm</var> <tt>upgrade</tt>
-		<var>new-version</var>
-	    </item>
-	    <item>
-		<var>new-prerm</var> <tt>failed-upgrade</tt>
-		<var>old-version</var>
-	    </item>
+	  The <prgn>postinst</prgn> script may be called in the following
+	  ways:
+	  <taglist>
+	    <tag><var>postinst</var> <tt>configure</tt>
+	      <var>most-recently-configured-version</var></tag>
 	    <item>
-		<var>conflictor's-prerm</var> <tt>remove</tt>
-		<tt>in-favour</tt> <var>package</var>
-		<var>new-version</var>
+	      The files contained in the package will be unpacked.  All
+	      package dependencies will at least be unpacked.  If there
+	      are no circular dependencies involved, all package
+	      dependencies will be configured.
 	    </item>
+
+	    <tag><var>old-postinst</var> <tt>abort-upgrade</tt>
+	      <var>new-version</var></tag>
+	    <tag><var>conflictor's-postinst</var> <tt>abort-remove</tt>
+	      <tt>in-favour</tt> <var>package</var>
+	      <var>new-version</var></tag>
+	    <tag><var>postinst</var> <tt>abort-remove</tt></tag>
+	    <tag><var>deconfigured's-postinst</var>
+	      <tt>abort-deconfigure</tt> <tt>in-favour</tt>
+	      <var>failed-install-package</var> <var>version</var>
+	      [<tt>removing</tt> <var>conflicting-package</var>
+	      <var>version</var>]</tag>
 	    <item>
-		<var>deconfigured's-prerm</var> <tt>deconfigure</tt>
-		<tt>in-favour</tt> <var>package-being-installed</var>
-		<var>version</var> [<tt>removing</tt>
-		<var>conflicting-package</var>
-		<var>version</var>]
+	      The files contained in the package will be unpacked.  All
+	      package dependencies will at least be "Half-Installed" and
+	      will have previously been configured and not removed.
+	      However, dependencies may not be configured or even fully
+	      unpacked in some error situations.<footnote>
+		For example, suppose packages foo and bar are installed
+		with foo depending on bar.  If an upgrade of bar were
+		started and then aborted, and then an attempt to remove
+		foo failed because its <prgn>prerm</prgn> script failed,
+		foo's <tt>postinst abort-remove</tt> would be called with
+		bar only "Half-Installed".
+	      </footnote>
 	    </item>
-	  </list>
+	  </taglist>
+	</p>
 
 	<p>
-	  <list compact="compact">
-	    <item>
-		<var>postrm</var> <tt>remove</tt>
-	    </item>
-	    <item>
-		<var>postrm</var> <tt>purge</tt>
-	    </item>
-	    <item>
-		<var>old-postrm</var> <tt>upgrade</tt>
-		<var>new-version</var>
-	    </item>
+	  The <prgn>prerm</prgn> script may be called in the following
+	  ways:
+	  <taglist>
+	    <tag><var>prerm</var> <tt>remove</tt></tag>
+	    <tag><var>old-prerm</var>
+	      <tt>upgrade</tt><var>new-version</var></tag>
+	    <tag><var>conflictor's-prerm</var> <tt>remove</tt>
+	      <tt>in-favour</tt> <var>package</var>
+	      <var>new-version</var></tag>
+	    <tag><var>deconfigured's-prerm</var> <tt>deconfigure</tt>
+	      <tt>in-favour</tt> <var>package-being-installed</var>
+	      <var>version</var> [<tt>removing</tt>
+	      <var>conflicting-package</var> <var>version</var>]</tag>
 	    <item>
-		<var>new-postrm</var> <tt>failed-upgrade</tt>
-		<var>old-version</var>
+	      The package whose <prgn>prerm</prgn> is being called will be
+	      at least "Half-Installed".  All package dependencies will at
+	      least be "Half-Installed" and will have previously been
+	      configured and not removed.  If there was no error, all
+	      dependencies will at least be unpacked, but these actions
+	      may be called in various error states where dependencies are
+	      only "Half-Installed" due to a partial upgrade.
 	    </item>
+
+	    <tag><var>new-prerm</var> <tt>failed-upgrade</tt>
+	      <var>old-version</var></tag>
 	    <item>
-		<var>new-postrm</var> <tt>abort-install</tt>
+	      Called during error handling when <tt>prerm upgrade</tt>
+	      fails.  The new package will not yet be unpacked, and all
+	      the same constraints as for <tt>preinst upgrade</tt> apply.
 	    </item>
+	  </taglist>
+	</p>
+
+	<p>
+	  The <prgn>postrm</prgn> script may be called in the following
+	  ways:
+	  <taglist>
+	    <tag><var>postrm</var> <tt>remove</tt></tag>
+	    <tag><var>postrm</var> <tt>purge</tt></tag>
+	    <tag><var>old-postrm</var> <tt>upgrade</tt>
+	      <var>new-version</var></tag>
+	    <tag><var>disappearer's-postrm</var> <tt>disappear</tt>
+		<var>overwriter</var> <var>overwriter-version</var></tag>
 	    <item>
-		<var>new-postrm</var> <tt>abort-install</tt>
-		<var>old-version</var>
+	      The <prgn>postrm</prgn> script is called after the package's
+	      files have been removed or replaced.  The package
+	      whose <prgn>postrm</prgn> is being called may have
+	      previously been deconfigured and only be unpacked, at which
+	      point subsequent package changes do not consider its
+	      dependencies.  Therefore, all <prgn>postrm</prgn> actions
+	      may only rely on essential packages and cannot assume that
+	      the package's dependencies are available.
 	    </item>
+
+	    <tag><var>new-postrm</var> <tt>failed-upgrade</tt>
+	      <var>old-version</var></tag>
 	    <item>
-		<var>new-postrm</var> <tt>abort-upgrade</tt>
-		<var>old-version</var>
+	      Called when the old <tt>postrm upgrade</tt> action fails.
+	      The new package will be unpacked, but only essential
+	      packages and pre-dependencies can be relied on.
+	      Pre-dependencies will either be configured or will be
+	      "Unpacked" or "Half-Configured" but previously had been
+	      configured and was never removed.
 	    </item>
+
+	    <tag><var>new-postrm</var> <tt>abort-install</tt></tag>
+	    <tag><var>new-postrm</var> <tt>abort-install</tt>
+	      <var>old-version</var></tag>
+	    <tag><var>new-postrm</var> <tt>abort-upgrade</tt>
+	      <var>old-version</var></tag>
 	    <item>
-		<var>disappearer's-postrm</var> <tt>disappear</tt>
-		<var>overwriter</var>
-		<var>overwriter-version</var>
+	      Called before unpackaging the new package as part of the
+	      error handling of <prgn>preinst</prgn> failures.  May assume
+	      the same state as <prgn>preinst</prgn> can assume.
 	    </item>
-	  </list>
+	  </taglist>
 	</p>
-
+      </sect>
 
       <sect id="unpackphase">
 	<heading>Details of unpack phase of installation or upgrade</heading>
@@ -4064,7 +4126,7 @@ Checksums-Sha256:
 		behavior which, though deterministic, is hard for the
 		system administrator to understand.  It can easily
 		lead to "missing" programs if, for example, a package
-		is installed which overwrites a file from another
+		is unpacked which overwrites a file from another
 		package, and is then removed again.<footnote>
 		    Part of the problem is due to what is arguably a
 		    bug in <prgn>dpkg</prgn>.
@@ -4200,7 +4262,7 @@ Checksums-Sha256:
 		If there was a conflicting package we go and do the
 		removal actions (described below), starting with the
 		removal of the conflicting package's files (any that
-		are also in the package being installed have already
+		are also in the package being unpacked have already
 		been removed from the conflicting package's file list,
 		and so do not get removed now).
 	    </item>
@@ -4540,31 +4602,31 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	</p>
 
 	<p>
-	  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.
+	  Since <tt>Depends</tt> only places requirements on the order in
+	  which packages are configured, packages in an installation run
+	  are usually all unpacked first and all configured later.  This
+	  allows multiple packages to be upgraded in one unpack and
+	  configure step even if some packages being upgraded have
+	  versioned dependencies on the upgraded versions of other
+	  packages involved in the installation run.
 	</p>
 
-        <p>
-          In case of circular dependencies, since installation or
-          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
-          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
-          all postinst scripts run with the dependencies properly
-          configured if this is possible. Otherwise the breaking point
-          is arbitrary.
-        </p>
-
 	<p>
-	  The <tt>Depends</tt> field thus allows package maintainers
-	  to impose an order in which packages should be configured.
+	  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 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 <prgn>postinst</prgn>
+	  script, then the cycle will be broken at that package; this
+	  ensures that all <prgn>postinst</prgn> scripts are run with
+	  their dependencies properly configured if this is possible.
+	  Otherwise the breaking point is arbitrary.  Packages should
+	  therefore avoid circular dependencies where possible,
+	  particularly if they have <prgn>postinst</prgn> scripts.
 	</p>
 
 	<p>
@@ -4576,7 +4638,8 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 		This declares an absolute dependency.  A package will
 		not be configured unless all of the packages listed in
 		its <tt>Depends</tt> field have been correctly
-		configured.
+		configured (unless there is a circular dependency as
+		described above).
 	      </p>
 
 	      <p>
@@ -4588,12 +4651,17 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 
 	      <p>
 		The <tt>Depends</tt> field should also be used if the
-		<prgn>postinst</prgn>, <prgn>prerm</prgn> or
-		<prgn>postrm</prgn> scripts require the package to be
-		present in order to run.  Note, however, that the
-		<prgn>postrm</prgn> cannot rely on any non-essential
-		packages to be present during the <tt>purge</tt>
-		phase.
+		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
+		require the depended-on package to be unpacked or
+		configured in order to run.  In the case of <tt>postinst
+		configure</tt>, the depended-on packages will be unpacked
+		and configured first.  (If both packages are involved in a
+		dependency loop, this might not work as expected; see the
+		explanation a few paragraphs back.)  In the case
+		of <prgn>prerm</prgn> or other <prgn>postinst</prgn>
+		actions, the package dependencies will be at least
+		unpacked or "Half-Installed".
+	      </p>
 	    </item>
 
 	    <tag><tt>Recommends</tt></tag>
@@ -4652,11 +4720,21 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	      </p>
 
 	      <p>
-		When the package declaring a pre-dependency is about
-		to be <em>configured</em>, the pre-dependency will be
-		treated as a normal <tt>Depends</tt>, that is, it will
-		be considered satisfied only if the depended-on
-		package has been correctly configured.
+		When the package declaring a pre-dependency is about to
+		be <em>configured</em>, the pre-dependency will be treated
+		as a normal <tt>Depends</tt>.  It will be considered
+		satisfied only if the depended-on package has been
+		correctly configured.  However, unlike
+		with <tt>Depends</tt>, <tt>Pre-Depends</tt> does not
+		permit circular dependencies to be broken.  If a circular
+		dependency is encountered while attempting to honor
+		<tt>Pre-Depends</tt>, the installation will be aborted.
+	      </p>
+
+	      <p>
+		<tt>Pre-Depends</tt> are also required if the
+		<prgn>preinst</prgn> script depends on the named package.
+		It is best to avoid this situation if possible.
 	      </p>
 
 	      <p>
@@ -4665,13 +4743,6 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 		installation would hamper the ability of the system to
 		continue with any upgrade that might be in progress.
 	      </p>
-
-	      <p>
-		<tt>Pre-Depends</tt> are also required if the
-		<prgn>preinst</prgn> script depends on the named
-		package.  It is best to avoid this situation if
-		possible.
-	      </p>
 	    </item>
 	  </taglist>
 	</p>
@@ -4696,7 +4767,7 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	<p>
 	  When one binary package declares that it breaks another,
 	  <prgn>dpkg</prgn> will refuse to allow the package which
-	  declares <tt>Breaks</tt> be installed unless the broken
+	  declares <tt>Breaks</tt> be unpacked unless the broken
 	  package is deconfigured first, and it will refuse to
 	  allow the broken package to be reconfigured.
 	</p>
@@ -4747,18 +4818,18 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	<heading>Conflicting binary packages - <tt>Conflicts</tt></heading>
 
 	<p>
-          When one binary package declares a conflict with another
-	  using a <tt>Conflicts</tt> field, <prgn>dpkg</prgn> will
-	  refuse to allow them to be installed on the system at the
-	  same time.  This is a stronger restriction than <tt>Breaks</tt>,
-	  which just prevents both packages from being configured at the
-	  same time.  Conflicting packages cannot be unpacked on the
-	  system at the same time.
+          When one binary package declares a conflict with another using
+	  a <tt>Conflicts</tt> field, <prgn>dpkg</prgn> will refuse to
+	  allow them to be unpacked on the system at the same time.  This
+	  is a stronger restriction than <tt>Breaks</tt>, which only
+	  prevents both packages from being configured at the same time.
+	  Conflicting packages cannot be unpacked on the system at the
+	  same time.
 	</p>
 
 	<p>
-	  If one package is to be installed, the other must be removed
-	  first.  If the package being installed is marked as replacing
+	  If one package is to be unpacked, the other must be removed
+	  first.  If the package being unpacked is marked as replacing
 	  (see <ref id="replaces">, but note that <tt>Breaks</tt> should
 	  normally be used in this case) the one on the system, or the one
 	  on the system is marked as deselected, or both packages are
@@ -5039,7 +5110,7 @@ Provides: mail-transport-agent
 Conflicts: mail-transport-agent
 Replaces: mail-transport-agent
 	    </example>
-	    ensuring that only one MTA can be installed at any one
+	    ensuring that only one MTA can be unpacked at any one
 	    time.  See <ref id="virtual"> for more information about this
 	    example.
 	</sect1>
@@ -5338,7 +5409,7 @@ Replaces: mail-transport-agent
          <footnote>
 	    <p>
 	      During install or upgrade, the preinst is called before
-	      the new files are installed, so calling "ldconfig" is
+	      the new files are unpacked, so calling "ldconfig" is
 	      pointless.  The preinst of an existing package can also be
 	      called if an upgrade fails.  However, this happens during
 	      the critical time when a shared libs may exist on-disk
@@ -5483,7 +5554,7 @@ Replaces: mail-transport-agent
 	<ref id="conflicts">) to ensure that the user only installs one
 	development version at a time (as different development versions are
 	likely to have the same header files in them, which would cause a
-	filename clash if both were installed).
+	filename clash if both were unpacked).
       </p>
 
       <p>
@@ -9774,7 +9845,7 @@ END-INFO-DIR-ENTRY
 	<p>
 	  The <prgn>DEBIAN</prgn> directory will not appear in the
 	  file system archive of the package, and so won't be installed
-	  by <prgn>dpkg</prgn> when the package is installed.
+	  by <prgn>dpkg</prgn> when the package is unpacked.
 	</p>
 
 	<p>

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Wed, 21 Jul 2010 22:39:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 21 Jul 2010 22:39:03 GMT) Full text and rfc822 format available.

Message #160 received at 504880@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Wed, 21 Jul 2010 17:34:53 -0500
Russ Allbery wrote:

> I found the original awkward and hard to puzzle out.  How about this:
> 
> 	<p>
> 	  Since <tt>Depends</tt> only places requirements on the order in
> 	  which packages are configured, packages in an installation run
> 	  are usually all unpacked first and all configured later.  [*]This
> 	  allows multiple packages to be upgraded in one unpack and
> 	  configure step even if some packages being upgraded have
> 	  versioned dependencies on the upgraded versions of other
> 	  packages involved in the installation run.
> 	</p>

The rationale makes sense.  The second sentence, which I have marked
with *, is getting a bit long and still does not have the charm of the
original.

> which hopefully re-adds the specific information.

Taking a step back, I can think of a few reasons to unpack everything
at the start of a dpkg run:

 1. It lumps output to the filesystem, which would be friendly to
    disks if we didn’t use fsync().

 2. Most packages work fine without any need to be configured.  So
    this makes the new packages available for use by local users
    as early as possible.

 3. Dependency resolution is very simple, since unpacking order
    is not constrained.  If Pre-Depends do not permit unpacking one
    of the packages, dpkg can error out right away.

 4. If there is a dependency loop, some packages will have to work
    well enough to satisfy dependencies (for postinst) without being
    configured.  If all packages involved are unpacked already, there
    is no need to do anything special to satisfy that kind of
    dependency.

I had thought the original was hinting at this fourth reason, but
after rereading it I think I must have been imagining that.  The
second and third reasons look to be more important, anyway.

I would suggest removing the confusing sentence.  It would be lovely
to document the reasons for this detail of dpkg’s design somewhere,
but it does not make the policy any more readable.

> Jonathan Nieder <jrnieder@gmail.com> writes:

>>> -	  The <tt>Depends</tt> field thus allows package maintainers
>>> -	  to impose an order in which packages should be configured.
>>>  	</p>
>
>> Is this removal intended?
> 
> Yes, it seems to just duplicate the first sentence of the paragraph above
> and the description of Depends later on.

Thanks; makes sense.

> 	      <p>
> 		The <tt>Depends</tt> field should also be used if the
> 		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
> 		require the depended-on package to be unpacked or
> 		configured in order to run.  In the case of <tt>postinst
> 		configure</tt>, the depended-on packages will be unpacked
> 		and configured first.  (If both packages are involved in a
> 		dependency loop, this might not work as expected; see the
> 		explanation a few paragraphs back.)

Nice.

>                                                    In the case
> 		of <prgn>prerm</prgn> or other <prgn>postinst</prgn>
> 		actions, the package dependencies will be at least
> 		unpacked or "Half-Installed".

Again, it will have been unpacked at some version and not removed
since then, right?  A very careful person can take advantage of
that.  Stealing your wording from elsewhere:

		                                     In the case
		of <prgn>prerm</prgn> or other <prgn>postinst</prgn>
		actions, the package dependencies will be at least
		unpacked, except they may be only "Half-Installed"
		if an upgrade of the dependency failed.

>> Whoops.
>
>> 	      This is a stronger restriction than <tt>Breaks</tt>,
>> 	which only prevents the broken package from being configured at
>> 	the same time as the breaking package is unpacked.
>
> I believe what I wrote is more correct than what you wrote.  What do you
> think is wrong about it which prompts the "whoops"?  Breaks allows both
> packages to be unpacked at the same time, but only one of the two packages
> can be configured at the same time.  Configuring one package will result
> in deconfiguring the other.

Breaks is an asymmetrical relationship: the constraint it imposes
is that the breaking package cannot be unpacked at the same time as
the broken package is configured.

Survey of dpkg code involving Breaks:

 * depisok will notice a package broken by a package to be unpacked.
   (If the to-be-broken package is half-configured, it is left alone.)

 * check_breaks uses depisok to determine whether to deconfigure a
   broken package or perhaps error out.  This is used when unpacking a
   new package (see process_archive).

 * predeppackage and check_conflict use depisok to handle Pre-Depends
   and Conflicts, respectively.

 * process_archive uses depisok directly to check Pre-Depends for
   all packages and reverse-(Depends/Pre-Depends/Recommends) for
   disappearing packages.

 * breakses_ok checks reverse-Breaks for a particular package, to
   decide whether to error out when attempting to configure it.

>  (At least.  I think under normal
> circumstances the broken package is then removed, although I'm not sure
> since Policy never says that.  All Policy says will happen is that it will
> be deconfigured.)

Right.  dpkg -B will deconfigure the package, but higher-level tools
tend to be more aggressive on the assumption that a broken package is
a useless package.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Wed, 21 Jul 2010 23:39:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 21 Jul 2010 23:39:09 GMT) Full text and rfc822 format available.

Message #165 received at 504880@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Wed, 21 Jul 2010 18:33:49 -0500
Russ Allbery wrote:

> Initial bootstrap, like udebs, feels to me like
> something that's outside the intended scope of Policy.

Note to self: beg Neil Williams to help edit a document based on
multistrap.

> Jonathan Nieder <jrnieder@gmail.com> writes:

>>  * postrm does not get called until pre-dependencies for the new
>>    version are satisfied.  So I think it is impossible for
>>    pre-dependencies to be half-installed here.
>
> I believe, from what Ian said, that it's possible if the pre-dependencies
> of the old version are different than the pre-dependencies of the new
> version and the upgrade of the pre-dependencies failed.

The following is only about "postrm upgrade" and "preinst abort-upgrade".

I don’t follow; could you explain further?  The order of operations
during an upgrade when all goes well is something like this:

	<check pre-dependencies>
	preinst upgrade
	<unpack>
	postrm upgrade
	... unpack other things ...
	<satisfy dependencies>
	postinst upgrade

In particular, if postrm fails, then pre-dependencies will have
already been checked...

[...]
> What I have now, given the above, is:
> 
> 	    <item>
> 	      Called during error handling of an upgrade that failed after
> 	      unpacking the new package because the <tt>postrm
> 	      upgrade</tt> action failed.  The unpacked files may be
> 	      partly from the new version or partly missing, so the script
> 	      cannot not rely on files included in the package.  Package
> 	      dependencies may not be available.  Pre-dependencies will be
> 	      at least unpacked following the same rules as above, except
> 	      they may be only "Half-Installed" if an upgrade of the
> 	      pre-dependency failed.
> 	    </item>

... so although I doubt it would come up in practice, I believe the
exception described in the last three lines can be removed.

> I think I'll just say this:
> 
> 	    <item>
> 	      Called during error handling when <tt>prerm upgrade</tt>
> 	      fails.  The new package will not yet be unpacked, and all
> 	      the same constraints as for <tt>preinst upgrade</tt> apply.
> 	    </item>

Very nice.   That does clear things up.

>> For upgrade, the new package will be unpacked already, right?  Maybe
>> that should be discussed in the same paragraph as failed-upgrade.
>
> I'm hesitant to do so since it may lead people to assume that files or
> dependencies are available since they would be provided by the new
> version, without realizing that they can't anticipate what the new version
> of the package may do and the new version may have completely different
> files and dependencies.

So as a matter of policy, the old postrm should not rely on files
from the new package to avoid unduly impeding future changes in the
package.  Makes a lot of sense.

Thanks for your thoughtfulness.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Thu, 22 Jul 2010 00:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 22 Jul 2010 00:03:02 GMT) Full text and rfc822 format available.

Message #170 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Wed, 21 Jul 2010 16:58:28 -0700
Jonathan Nieder <jrnieder@gmail.com> writes:
> Russ Allbery wrote:
>> Jonathan Nieder <jrnieder@gmail.com> writes:

>>>  * postrm does not get called until pre-dependencies for the new
>>>    version are satisfied.  So I think it is impossible for
>>>    pre-dependencies to be half-installed here.

>> I believe, from what Ian said, that it's possible if the
>> pre-dependencies of the old version are different than the
>> pre-dependencies of the new version and the upgrade of the
>> pre-dependencies failed.

> The following is only about "postrm upgrade" and "preinst abort-upgrade".

> I don’t follow; could you explain further?  The order of operations
> during an upgrade when all goes well is something like this:

> 	<check pre-dependencies>
> 	preinst upgrade
> 	<unpack>
> 	postrm upgrade
> 	... unpack other things ...
> 	<satisfy dependencies>
> 	postinst upgrade

> In particular, if postrm fails, then pre-dependencies will have already
> been checked...

Suppose that you have a package foo 1.0-1 with:

    Pre-Depends: bar

and a package foo 2.0-1 that has no pre-dependencies.  foo and bar are
both currently installed.  Now, you:

    dpkg -i bar_2.0-1.deb
    ^C

(or something else bad happens in the middle).  bar is now half-installed.
Nothing has happened to foo because attempted upgrades of dependencies and
pre-dependencies do not require deconfiguring packages.

Now you run:

    dpkg -i foo_2.0-1.deb

foo 2.0-1 has no pre-dependencies, so the pre-dependency check succeeds.
Installation proceeds and foo 2.0-1 is unpacked, and then the foo 1.0-1
postrm upgrade fails.  Error unwind happens and the foo 1.0-1 preinst is
called with abort-upgrade.  bar is only half-installed.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Thu, 22 Jul 2010 00:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 22 Jul 2010 00:18:03 GMT) Full text and rfc822 format available.

Message #175 received at 504880@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Wed, 21 Jul 2010 19:15:24 -0500
Russ Allbery wrote:

> Suppose that you have a package foo 1.0-1 with:
> 
>     Pre-Depends: bar
> 
> and a package foo 2.0-1 that has no pre-dependencies.
[...]
> Now you run:
> 
>     dpkg -i foo_2.0-1.deb
> 
> foo 2.0-1 has no pre-dependencies, so the pre-dependency check succeeds.
> Installation proceeds and foo 2.0-1 is unpacked, and then the foo 1.0-1
> postrm upgrade fails.  Error unwind happens and the foo 1.0-1 preinst is
> called with abort-upgrade.  bar is only half-installed.

Ah, the “you can’t depend on future maintainers” rule again.

|	                                  Pre-dependencies will be
|	at least unpacked following the same rules as above, except
|	they may be only "Half-Installed" if an upgrade of the
|	pre-dependency failed.

Maybe a footnote would be appropriate - something like

	[1] This can happen if the new package no longer pre-depends
	on a package that has been partially upgraded.

Thanks for the explanation.
Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sat, 24 Jul 2010 22:21:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 24 Jul 2010 22:21:04 GMT) Full text and rfc822 format available.

Message #180 received at 504880@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: Jonathan Nieder <jrnieder@gmail.com>, 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sat, 24 Jul 2010 10:59:51 -0700
[Message part 1 (text/plain, inline)]
On Wed, Jul 21, 2010 at 01:37:28PM -0700, Russ Allbery wrote:
> >>  	<p>
> >>            When one binary package declares a conflict with another
> >>  	  using a <tt>Conflicts</tt> field, <prgn>dpkg</prgn> will
> >> -	  refuse to allow them to be installed on the system at the
> >> +	  refuse to allow them to be unpacked on the system at the
> >>  	  same time.  This is a stronger restriction than <tt>Breaks</tt>,
> >>  	  which just prevents both packages from being configured at the
> >>  	  same time.  Conflicting packages cannot be unpacked on the

> > Whoops.

> > 	      This is a stronger restriction than <tt>Breaks</tt>,
> > 	which only prevents the broken package from being configured at
> > 	the same time as the breaking package is unpacked.

> I believe what I wrote is more correct than what you wrote.  What do you
> think is wrong about it which prompts the "whoops"?  Breaks allows both
> packages to be unpacked at the same time, but only one of the two packages
> can be configured at the same time.  Configuring one package will result
> in deconfiguring the other.  (At least.  I think under normal
> circumstances the broken package is then removed, although I'm not sure
> since Policy never says that.  All Policy says will happen is that it will
> be deconfigured.)

I don't think it's a "whoops", but it is true that Breaks is asymmetric and
it's specifically the /broken/ package that is deconfigured when the
/breaking/ package is unpacked, and I think Policy should be clear about
this.  (Yes, the fact that the package manager normally proceeds to remove
the broken package is an apt policy, not Policy.)

So I think it's better to say:

  	This is a stronger restriction than <tt>Breaks</tt>, which just
	prevents the package listed in the Breaks field from being
	configured while the package with the Breaks field is present on
	the system.

Avoids referring to packages listed in Breaks as 'broken', which it seems
we're trying to do even though we use the common English verbs throughout
Policy for the other relationship fields; and avoids the ambiguous "is
unpacked" where what we really mean is the much more bulky "is in an
unpacked state".  The whole thing comes out pretty awkward for all that, but
I have no ideas on further improving it.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sat, 24 Jul 2010 22:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 24 Jul 2010 22:51:03 GMT) Full text and rfc822 format available.

Message #185 received at 504880@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>, 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sat, 24 Jul 2010 17:46:01 -0500
Steve Langasek wrote:

> So I think it's better to say:
> 
>   	This is a stronger restriction than <tt>Breaks</tt>, which just
> 	prevents the package listed in the Breaks field from being
> 	configured while the package with the Breaks field is present on
> 	the system.
> 
> Avoids referring to packages listed in Breaks as 'broken', which it seems
> we're trying to do even though we use the common English verbs throughout
> Policy for the other relationship fields; and avoids the ambiguous "is
> unpacked" where what we really mean is the much more bulky "is in an
> unpacked state".

Sounds good to me, especially since earlier passages make that more
precise already.

Thanks.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Mon, 26 Jul 2010 21:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 26 Jul 2010 21:39:03 GMT) Full text and rfc822 format available.

Message #190 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Mon, 26 Jul 2010 14:36:28 -0700
Steve Langasek <vorlon@debian.org> writes:

> I don't think it's a "whoops", but it is true that Breaks is asymmetric
> and it's specifically the /broken/ package that is deconfigured when the
> /breaking/ package is unpacked, and I think Policy should be clear about
> this.  (Yes, the fact that the package manager normally proceeds to
> remove the broken package is an apt policy, not Policy.)

> So I think it's better to say:

>   	This is a stronger restriction than <tt>Breaks</tt>, which just
> 	prevents the package listed in the Breaks field from being
> 	configured while the package with the Breaks field is present on
> 	the system.

> Avoids referring to packages listed in Breaks as 'broken', which it
> seems we're trying to do even though we use the common English verbs
> throughout Policy for the other relationship fields; and avoids the
> ambiguous "is unpacked" where what we really mean is the much more bulky
> "is in an unpacked state".  The whole thing comes out pretty awkward for
> all that, but I have no ideas on further improving it.

I now have:

	<p>
          When one binary package declares a conflict with another using
	  a <tt>Conflicts</tt> field, <prgn>dpkg</prgn> will refuse to
	  allow them to be unpacked on the system at the same time.  This
	  is a stronger restriction than <tt>Breaks</tt>, which prevents
	  the broken package from being configured while the breaking
	  package is in the "Unpacked" state but allows both packages to
	  be unpacked at the same time.
	</p>

We do use "breaking" and "broken" elsewhere in Policy with respect to the
Breaks header, so I felt comfortable using them here.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Mon, 26 Jul 2010 21:39:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 26 Jul 2010 21:39:05 GMT) Full text and rfc822 format available.

Message #195 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Mon, 26 Jul 2010 14:37:46 -0700
Jonathan Nieder <jrnieder@gmail.com> writes:

> |	                                  Pre-dependencies will be
> |	at least unpacked following the same rules as above, except
> |	they may be only "Half-Installed" if an upgrade of the
> |	pre-dependency failed.

> Maybe a footnote would be appropriate - something like

> 	[1] This can happen if the new package no longer pre-depends
> 	on a package that has been partially upgraded.

Added, thanks!

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Mon, 26 Jul 2010 21:42:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 26 Jul 2010 21:42:06 GMT) Full text and rfc822 format available.

Message #200 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Mon, 26 Jul 2010 14:39:40 -0700
Jonathan Nieder <jrnieder@gmail.com> writes:
> Russ Allbery wrote:

>> I found the original awkward and hard to puzzle out.  How about this:
>> 
>> 	<p>
>> 	  Since <tt>Depends</tt> only places requirements on the order in
>> 	  which packages are configured, packages in an installation run
>> 	  are usually all unpacked first and all configured later.  [*]This
>> 	  allows multiple packages to be upgraded in one unpack and
>> 	  configure step even if some packages being upgraded have
>> 	  versioned dependencies on the upgraded versions of other
>> 	  packages involved in the installation run.
>> 	</p>

> The rationale makes sense.  The second sentence, which I have marked
> with *, is getting a bit long and still does not have the charm of the
> original.

How about this:

     <p>
       Since <tt>Depends</tt> only places requirements on the order in
       which packages are configured, packages in an installation run
       are usually all unpacked first and all configured later.
       <footnote>
         This approach makes dependency resolution easier.  If two
         packages A and B are being upgraded, the installed package A
         depends on exactly the installed package B, and the new
         package A depends on exactly the new package B (a common
         situation when upgrading shared libraries and their
         corresponding development packages), satisfying the
         dependencies at every stage of the upgrade would be
         impossible.  This relaxed restriction means that both new
         packages can be unpacked together and then configured in their
         dependency order.
       </footnote>
     </p>

That moves the whole thing into a footnote and gives a more specific
example.

>>                                                    In the case
>> 		of <prgn>prerm</prgn> or other <prgn>postinst</prgn>
>> 		actions, the package dependencies will be at least
>> 		unpacked or "Half-Installed".

> Again, it will have been unpacked at some version and not removed
> since then, right?  A very careful person can take advantage of
> that.  Stealing your wording from elsewhere:

> 		                                     In the case
> 		of <prgn>prerm</prgn> or other <prgn>postinst</prgn>
> 		actions, the package dependencies will be at least
> 		unpacked, except they may be only "Half-Installed"
> 		if an upgrade of the dependency failed.

I now have:

                In the case
                of <prgn>prerm</prgn> or other <prgn>postinst</prgn>
                actions, the package dependencies will normally be at
                least unpacked, but they may be only "Half-Installed" if a
                previous upgrade of the dependency failed.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Mon, 26 Jul 2010 21:48:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 26 Jul 2010 21:48:03 GMT) Full text and rfc822 format available.

Message #205 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 504880@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Mon, 26 Jul 2010 14:44:14 -0700
Here is an updated version of the proposed patch, reflecting additional
feedback.  I think we should hopefully be close to a final wording now.

diff --git a/policy.sgml b/policy.sgml
index e5134ed..9e8689e 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1079,10 +1079,10 @@
 	</p>
 
 	<p>
-	  Sometimes, a package requires another package to be installed
-	  <em>and</em> configured before it can be installed. In this
-	  case, you must specify a <tt>Pre-Depends</tt> entry for
-	  the package.
+	  Sometimes, unpacking one package requires that another package
+	  be first unpacked <em>and</em> configured.  In this case, the
+	  dependent package must specify this dependency in
+	  the <tt>Pre-Depends</tt> control field.
 	</p>
 
 	<p>
@@ -3683,7 +3683,7 @@ Checksums-Sha256:
 
 	<p>
 	  Broadly speaking the <prgn>preinst</prgn> is called before
-	  (a particular version of) a package is installed, and the
+	  (a particular version of) a package is unpacked, and the
 	  <prgn>postinst</prgn> afterwards; the <prgn>prerm</prgn>
 	  before (a version of) a package is removed and the
 	  <prgn>postrm</prgn> afterwards.
@@ -3767,111 +3767,177 @@ Checksums-Sha256:
 	</heading>
 
 	<p>
-	  <list compact="compact">
-	    <item>
-	      <var>new-preinst</var> <tt>install</tt>
-	    </item>
-	    <item>
-	      <var>new-preinst</var> <tt>install</tt> <var>old-version</var>
-	    </item>
-	    <item>
-		<var>new-preinst</var> <tt>upgrade</tt> <var>old-version</var>
-	    </item>
-	    <item>
-		<var>old-preinst</var> <tt>abort-upgrade</tt>
-		<var>new-version</var>
-	    </item>
-	  </list>
+	  What follows is a summary of all the ways in which maintainer
+	  scripts may be called along with what facilities those scripts
+	  may rely on being available at that time.  Script names preceded
+	  by <var>new-</var> are the scripts from the new version of a
+	  package being installed, upgraded to, or downgraded to.  Script
+	  names preceded by <var>old-</var> are the scripts from the old
+	  version of a package that is being upgraded from or downgraded
+	  from.
+	</p>
 
 	<p>
-	  <list compact="compact">
-	    <item>
-		<var>postinst</var> <tt>configure</tt>
-		<var>most-recently-configured-version</var>
-	    </item>
-	    <item>
-		<var>old-postinst</var> <tt>abort-upgrade</tt>
-		<var>new-version</var>
-	    </item>
-	    <item>
-		<var>conflictor's-postinst</var> <tt>abort-remove</tt>
-		<tt>in-favour</tt> <var>package</var>
-		<var>new-version</var>
-	    </item>
+	  The <prgn>preinst</prgn> script may be called in the following
+	  ways:
+	  <taglist>
+	    <tag><var>new-preinst</var> <tt>install</tt></tag>
+	    <tag><var>new-preinst</var> <tt>install</tt>
+	      <var>old-version</var></tag>
+	    <tag><var>new-preinst</var> <tt>upgrade</tt>
+	      <var>old-version</var></tag>
 	    <item>
-		<var>postinst</var> <tt>abort-remove</tt>
+	      The package will not yet be unpacked, so
+	      the <prgn>preinst</prgn> script cannot rely on any files
+	      included in its package.  Only essential packages and
+	      pre-dependencies (<tt>Pre-Depends</tt>) may be assumed to be
+	      available.  Pre-dependencies will be at least unpacked.
+	      They may be only unpacked or "Half-Configured", not
+	      completely configured, but only if a previous version of the
+	      pre-dependency was completely configured and the
+	      pre-dependency had not been removed since then.
 	    </item>
+
+	    <tag><var>old-preinst</var> <tt>abort-upgrade</tt>
+	      <var>new-version</var></tag>
 	    <item>
-		<var>deconfigured's-postinst</var>
-		<tt>abort-deconfigure</tt> <tt>in-favour</tt>
-		<var>failed-install-package</var> <var>version</var>
-		[<tt>removing</tt> <var>conflicting-package</var>
-		<var>version</var>]
+	      Called during error handling of an upgrade that failed after
+	      unpacking the new package because the <tt>postrm
+	      upgrade</tt> action failed.  The unpacked files may be
+	      partly from the new version or partly missing, so the script
+	      cannot not rely on files included in the package.  Package
+	      dependencies may not be available.  Pre-dependencies will be
+	      at least unpacked following the same rules as above, except
+	      they may be only "Half-Installed" if an upgrade of the
+	      pre-dependency failed.<footnote>
+		This can happen if the new version of the package no
+		longer pre-depends on a package that had been partially
+		upgraded.
+	      </footnote>
 	    </item>
-	  </list>
+	  </taglist>
+	</p>
 
 	<p>
-	  <list compact="compact">
-	    <item>
-		<var>prerm</var> <tt>remove</tt>
-	    </item>
-	    <item>
-		<var>old-prerm</var> <tt>upgrade</tt>
-		<var>new-version</var>
-	    </item>
-	    <item>
-		<var>new-prerm</var> <tt>failed-upgrade</tt>
-		<var>old-version</var>
-	    </item>
+	  The <prgn>postinst</prgn> script may be called in the following
+	  ways:
+	  <taglist>
+	    <tag><var>postinst</var> <tt>configure</tt>
+	      <var>most-recently-configured-version</var></tag>
 	    <item>
-		<var>conflictor's-prerm</var> <tt>remove</tt>
-		<tt>in-favour</tt> <var>package</var>
-		<var>new-version</var>
+	      The files contained in the package will be unpacked.  All
+	      package dependencies will at least be unpacked.  If there
+	      are no circular dependencies involved, all package
+	      dependencies will be configured.
 	    </item>
+
+	    <tag><var>old-postinst</var> <tt>abort-upgrade</tt>
+	      <var>new-version</var></tag>
+	    <tag><var>conflictor's-postinst</var> <tt>abort-remove</tt>
+	      <tt>in-favour</tt> <var>package</var>
+	      <var>new-version</var></tag>
+	    <tag><var>postinst</var> <tt>abort-remove</tt></tag>
+	    <tag><var>deconfigured's-postinst</var>
+	      <tt>abort-deconfigure</tt> <tt>in-favour</tt>
+	      <var>failed-install-package</var> <var>version</var>
+	      [<tt>removing</tt> <var>conflicting-package</var>
+	      <var>version</var>]</tag>
 	    <item>
-		<var>deconfigured's-prerm</var> <tt>deconfigure</tt>
-		<tt>in-favour</tt> <var>package-being-installed</var>
-		<var>version</var> [<tt>removing</tt>
-		<var>conflicting-package</var>
-		<var>version</var>]
+	      The files contained in the package will be unpacked.  All
+	      package dependencies will at least be "Half-Installed" and
+	      will have previously been configured and not removed.
+	      However, dependencies may not be configured or even fully
+	      unpacked in some error situations.<footnote>
+		For example, suppose packages foo and bar are installed
+		with foo depending on bar.  If an upgrade of bar were
+		started and then aborted, and then an attempt to remove
+		foo failed because its <prgn>prerm</prgn> script failed,
+		foo's <tt>postinst abort-remove</tt> would be called with
+		bar only "Half-Installed".
+	      </footnote>
 	    </item>
-	  </list>
+	  </taglist>
+	</p>
 
 	<p>
-	  <list compact="compact">
-	    <item>
-		<var>postrm</var> <tt>remove</tt>
-	    </item>
-	    <item>
-		<var>postrm</var> <tt>purge</tt>
-	    </item>
-	    <item>
-		<var>old-postrm</var> <tt>upgrade</tt>
-		<var>new-version</var>
-	    </item>
+	  The <prgn>prerm</prgn> script may be called in the following
+	  ways:
+	  <taglist>
+	    <tag><var>prerm</var> <tt>remove</tt></tag>
+	    <tag><var>old-prerm</var>
+	      <tt>upgrade</tt><var>new-version</var></tag>
+	    <tag><var>conflictor's-prerm</var> <tt>remove</tt>
+	      <tt>in-favour</tt> <var>package</var>
+	      <var>new-version</var></tag>
+	    <tag><var>deconfigured's-prerm</var> <tt>deconfigure</tt>
+	      <tt>in-favour</tt> <var>package-being-installed</var>
+	      <var>version</var> [<tt>removing</tt>
+	      <var>conflicting-package</var> <var>version</var>]</tag>
 	    <item>
-		<var>new-postrm</var> <tt>failed-upgrade</tt>
-		<var>old-version</var>
+	      The package whose <prgn>prerm</prgn> is being called will be
+	      at least "Half-Installed".  All package dependencies will at
+	      least be "Half-Installed" and will have previously been
+	      configured and not removed.  If there was no error, all
+	      dependencies will at least be unpacked, but these actions
+	      may be called in various error states where dependencies are
+	      only "Half-Installed" due to a partial upgrade.
 	    </item>
+
+	    <tag><var>new-prerm</var> <tt>failed-upgrade</tt>
+	      <var>old-version</var></tag>
 	    <item>
-		<var>new-postrm</var> <tt>abort-install</tt>
+	      Called during error handling when <tt>prerm upgrade</tt>
+	      fails.  The new package will not yet be unpacked, and all
+	      the same constraints as for <tt>preinst upgrade</tt> apply.
 	    </item>
+	  </taglist>
+	</p>
+
+	<p>
+	  The <prgn>postrm</prgn> script may be called in the following
+	  ways:
+	  <taglist>
+	    <tag><var>postrm</var> <tt>remove</tt></tag>
+	    <tag><var>postrm</var> <tt>purge</tt></tag>
+	    <tag><var>old-postrm</var> <tt>upgrade</tt>
+	      <var>new-version</var></tag>
+	    <tag><var>disappearer's-postrm</var> <tt>disappear</tt>
+		<var>overwriter</var> <var>overwriter-version</var></tag>
 	    <item>
-		<var>new-postrm</var> <tt>abort-install</tt>
-		<var>old-version</var>
+	      The <prgn>postrm</prgn> script is called after the package's
+	      files have been removed or replaced.  The package
+	      whose <prgn>postrm</prgn> is being called may have
+	      previously been deconfigured and only be unpacked, at which
+	      point subsequent package changes do not consider its
+	      dependencies.  Therefore, all <prgn>postrm</prgn> actions
+	      may only rely on essential packages and cannot assume that
+	      the package's dependencies are available.
 	    </item>
+
+	    <tag><var>new-postrm</var> <tt>failed-upgrade</tt>
+	      <var>old-version</var></tag>
 	    <item>
-		<var>new-postrm</var> <tt>abort-upgrade</tt>
-		<var>old-version</var>
+	      Called when the old <tt>postrm upgrade</tt> action fails.
+	      The new package will be unpacked, but only essential
+	      packages and pre-dependencies can be relied on.
+	      Pre-dependencies will either be configured or will be
+	      "Unpacked" or "Half-Configured" but previously had been
+	      configured and was never removed.
 	    </item>
+
+	    <tag><var>new-postrm</var> <tt>abort-install</tt></tag>
+	    <tag><var>new-postrm</var> <tt>abort-install</tt>
+	      <var>old-version</var></tag>
+	    <tag><var>new-postrm</var> <tt>abort-upgrade</tt>
+	      <var>old-version</var></tag>
 	    <item>
-		<var>disappearer's-postrm</var> <tt>disappear</tt>
-		<var>overwriter</var>
-		<var>overwriter-version</var>
+	      Called before unpackaging the new package as part of the
+	      error handling of <prgn>preinst</prgn> failures.  May assume
+	      the same state as <prgn>preinst</prgn> can assume.
 	    </item>
-	  </list>
+	  </taglist>
 	</p>
-
+      </sect>
 
       <sect id="unpackphase">
 	<heading>Details of unpack phase of installation or upgrade</heading>
@@ -4073,7 +4139,7 @@ Checksums-Sha256:
 		behavior which, though deterministic, is hard for the
 		system administrator to understand.  It can easily
 		lead to "missing" programs if, for example, a package
-		is installed which overwrites a file from another
+		is unpacked which overwrites a file from another
 		package, and is then removed again.<footnote>
 		    Part of the problem is due to what is arguably a
 		    bug in <prgn>dpkg</prgn>.
@@ -4209,7 +4275,7 @@ Checksums-Sha256:
 		If there was a conflicting package we go and do the
 		removal actions (described below), starting with the
 		removal of the conflicting package's files (any that
-		are also in the package being installed have already
+		are also in the package being unpacked have already
 		been removed from the conflicting package's file list,
 		and so do not get removed now).
 	    </item>
@@ -4549,31 +4615,39 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	</p>
 
 	<p>
-	  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.
+	  Since <tt>Depends</tt> only places requirements on the order in
+	  which packages are configured, packages in an installation run
+	  are usually all unpacked first and all configured later.
+	  <footnote>
+	    This approach makes dependency resolution easier.  If two
+	    packages A and B are being upgraded, the installed package A
+	    depends on exactly the installed package B, and the new
+	    package A depends on exactly the new package B (a common
+	    situation when upgrading shared libraries and their
+	    corresponding development packages), satisfying the
+	    dependencies at every stage of the upgrade would be
+	    impossible.  This relaxed restriction means that both new
+	    packages can be unpacked together and then configured in their
+	    dependency order.
+	  </footnote>
 	</p>
 
-        <p>
-          In case of circular dependencies, since installation or
-          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
-          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
-          all postinst scripts run with the dependencies properly
-          configured if this is possible. Otherwise the breaking point
-          is arbitrary.
-        </p>
-
 	<p>
-	  The <tt>Depends</tt> field thus allows package maintainers
-	  to impose an order in which packages should be configured.
+	  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 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 <prgn>postinst</prgn>
+	  script, then the cycle will be broken at that package; this
+	  ensures that all <prgn>postinst</prgn> scripts are run with
+	  their dependencies properly configured if this is possible.
+	  Otherwise the breaking point is arbitrary.  Packages should
+	  therefore avoid circular dependencies where possible,
+	  particularly if they have <prgn>postinst</prgn> scripts.
 	</p>
 
 	<p>
@@ -4585,7 +4659,8 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 		This declares an absolute dependency.  A package will
 		not be configured unless all of the packages listed in
 		its <tt>Depends</tt> field have been correctly
-		configured.
+		configured (unless there is a circular dependency as
+		described above).
 	      </p>
 
 	      <p>
@@ -4597,12 +4672,18 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 
 	      <p>
 		The <tt>Depends</tt> field should also be used if the
-		<prgn>postinst</prgn>, <prgn>prerm</prgn> or
-		<prgn>postrm</prgn> scripts require the package to be
-		present in order to run.  Note, however, that the
-		<prgn>postrm</prgn> cannot rely on any non-essential
-		packages to be present during the <tt>purge</tt>
-		phase.
+		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
+		require the depended-on package to be unpacked or
+		configured in order to run.  In the case of <tt>postinst
+		configure</tt>, the depended-on packages will be unpacked
+		and configured first.  (If both packages are involved in a
+		dependency loop, this might not work as expected; see the
+		explanation a few paragraphs back.)  In the case
+		of <prgn>prerm</prgn> or other <prgn>postinst</prgn>
+		actions, the package dependencies will normally be at
+		least unpacked, but they may be only "Half-Installed" if a
+		previous upgrade of the dependency failed.
+	      </p>
 	    </item>
 
 	    <tag><tt>Recommends</tt></tag>
@@ -4661,11 +4742,21 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	      </p>
 
 	      <p>
-		When the package declaring a pre-dependency is about
-		to be <em>configured</em>, the pre-dependency will be
-		treated as a normal <tt>Depends</tt>, that is, it will
-		be considered satisfied only if the depended-on
-		package has been correctly configured.
+		When the package declaring a pre-dependency is about to
+		be <em>configured</em>, the pre-dependency will be treated
+		as a normal <tt>Depends</tt>.  It will be considered
+		satisfied only if the depended-on package has been
+		correctly configured.  However, unlike
+		with <tt>Depends</tt>, <tt>Pre-Depends</tt> does not
+		permit circular dependencies to be broken.  If a circular
+		dependency is encountered while attempting to honor
+		<tt>Pre-Depends</tt>, the installation will be aborted.
+	      </p>
+
+	      <p>
+		<tt>Pre-Depends</tt> are also required if the
+		<prgn>preinst</prgn> script depends on the named package.
+		It is best to avoid this situation if possible.
 	      </p>
 
 	      <p>
@@ -4674,13 +4765,6 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 		installation would hamper the ability of the system to
 		continue with any upgrade that might be in progress.
 	      </p>
-
-	      <p>
-		<tt>Pre-Depends</tt> are also required if the
-		<prgn>preinst</prgn> script depends on the named
-		package.  It is best to avoid this situation if
-		possible.
-	      </p>
 	    </item>
 	  </taglist>
 	</p>
@@ -4705,7 +4789,7 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	<p>
 	  When one binary package declares that it breaks another,
 	  <prgn>dpkg</prgn> will refuse to allow the package which
-	  declares <tt>Breaks</tt> be installed unless the broken
+	  declares <tt>Breaks</tt> be unpacked unless the broken
 	  package is deconfigured first, and it will refuse to
 	  allow the broken package to be reconfigured.
 	</p>
@@ -4756,18 +4840,18 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	<heading>Conflicting binary packages - <tt>Conflicts</tt></heading>
 
 	<p>
-          When one binary package declares a conflict with another
-	  using a <tt>Conflicts</tt> field, <prgn>dpkg</prgn> will
-	  refuse to allow them to be installed on the system at the
-	  same time.  This is a stronger restriction than <tt>Breaks</tt>,
-	  which just prevents both packages from being configured at the
-	  same time.  Conflicting packages cannot be unpacked on the
-	  system at the same time.
+          When one binary package declares a conflict with another using
+	  a <tt>Conflicts</tt> field, <prgn>dpkg</prgn> will refuse to
+	  allow them to be unpacked on the system at the same time.  This
+	  is a stronger restriction than <tt>Breaks</tt>, which prevents
+	  the broken package from being configured while the breaking
+	  package is in the "Unpacked" state but allows both packages to
+	  be unpacked at the same time.
 	</p>
 
 	<p>
-	  If one package is to be installed, the other must be removed
-	  first.  If the package being installed is marked as replacing
+	  If one package is to be unpacked, the other must be removed
+	  first.  If the package being unpacked is marked as replacing
 	  (see <ref id="replaces">, but note that <tt>Breaks</tt> should
 	  normally be used in this case) the one on the system, or the one
 	  on the system is marked as deselected, or both packages are
@@ -4816,7 +4900,7 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	    <item>when two packages provide the same file and will
 	      continue to do so,</item>
 	    <item>in conjunction with <tt>Provides</tt> when only one
-	      package providing a given virtual facility may be installed
+	      package providing a given virtual facility may be unpacked
 	      at a time (see <ref id="virtual">),</item>
 	    <item>in other cases where one must prevent simultaneous
 	      installation of two packages for reasons that are ongoing
@@ -5048,7 +5132,7 @@ Provides: mail-transport-agent
 Conflicts: mail-transport-agent
 Replaces: mail-transport-agent
 	    </example>
-	    ensuring that only one MTA can be installed at any one
+	    ensuring that only one MTA can be unpacked at any one
 	    time.  See <ref id="virtual"> for more information about this
 	    example.
 	</sect1>
@@ -5347,7 +5431,7 @@ Replaces: mail-transport-agent
          <footnote>
 	    <p>
 	      During install or upgrade, the preinst is called before
-	      the new files are installed, so calling "ldconfig" is
+	      the new files are unpacked, so calling "ldconfig" is
 	      pointless.  The preinst of an existing package can also be
 	      called if an upgrade fails.  However, this happens during
 	      the critical time when a shared libs may exist on-disk
@@ -5492,7 +5576,7 @@ Replaces: mail-transport-agent
 	<ref id="conflicts">) to ensure that the user only installs one
 	development version at a time (as different development versions are
 	likely to have the same header files in them, which would cause a
-	filename clash if both were installed).
+	filename clash if both were unpacked).
       </p>
 
       <p>
@@ -9814,7 +9898,7 @@ END-INFO-DIR-ENTRY
 	<p>
 	  The <prgn>DEBIAN</prgn> directory will not appear in the
 	  file system archive of the package, and so won't be installed
-	  by <prgn>dpkg</prgn> when the package is installed.
+	  by <prgn>dpkg</prgn> when the package is unpacked.
 	</p>
 
 	<p>

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Mon, 26 Jul 2010 22:45:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 26 Jul 2010 22:45:06 GMT) Full text and rfc822 format available.

Message #210 received at 504880@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: 504880@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Mon, 26 Jul 2010 17:30:34 -0500
Russ Allbery wrote:

> I think we should hopefully be close to a final wording now.

Indeed!  All I have left are copy-edits (patch below).

> +++ b/policy.sgml
[...]
> +	                                   The unpacked files may be
> +	      partly from the new version or partly missing, so the script
> +	      cannot not

s/ not//

>  	                 rely on files included in the package.
[...]
> +	      Called before unpackaging 

s/unpackaging/unpacking/

>  	                                the new package as part of the
> +	      error handling of <prgn>preinst</prgn> failures.
[...]
>  	  When one binary package declares that it breaks another,
>  	  <prgn>dpkg</prgn> will refuse to allow the package which
> -	  declares <tt>Breaks</tt> be installed unless the broken
> +	  declares <tt>Breaks</tt> be unpacked unless the broken

s/be/to be/

> @@ -5048,7 +5132,7 @@ Provides: mail-transport-agent
>  Conflicts: mail-transport-agent
>  Replaces: mail-transport-agent
>  	    </example>
> -	    ensuring that only one MTA can be installed at any one
> +	    ensuring that only one MTA can be unpacked at any one
>  	    time.  See <ref id="virtual"> for more information about this
>  	    example.
>  	</sect1>

Aside: is this advice right?  Maybe we should be encouraging

 Provides: mail-transport-agent
 Breaks: mail-transport-agent
 Replaces: mail-transport-agent

instead.

The new text looks very good.  Thanks again.

-- 8< --
Subject: Three typos
---
diff --git i/policy.sgml w/policy.sgml
index 3c63507..406301e 100644
--- i/policy.sgml
+++ w/policy.sgml
@@ -3805,7 +3805,7 @@ Checksums-Sha256:
 	      unpacking the new package because the <tt>postrm
 	      upgrade</tt> action failed.  The unpacked files may be
 	      partly from the new version or partly missing, so the script
-	      cannot not rely on files included in the package.  Package
+	      cannot rely on files included in the package.  Package
 	      dependencies may not be available.  Pre-dependencies will be
 	      at least unpacked following the same rules as above, except
 	      they may be only "Half-Installed" if an upgrade of the
@@ -3927,7 +3927,7 @@ Checksums-Sha256:
 	    <tag><var>new-postrm</var> <tt>abort-upgrade</tt>
 	      <var>old-version</var></tag>
 	    <item>
-	      Called before unpackaging the new package as part of the
+	      Called before unpacking the new package as part of the
 	      error handling of <prgn>preinst</prgn> failures.  May assume
 	      the same state as <prgn>preinst</prgn> can assume.
 	    </item>
@@ -4776,7 +4776,7 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	<p>
 	  When one binary package declares that it breaks another,
 	  <prgn>dpkg</prgn> will refuse to allow the package which
-	  declares <tt>Breaks</tt> be unpacked unless the broken
+	  declares <tt>Breaks</tt> to be unpacked unless the broken
 	  package is deconfigured first, and it will refuse to
 	  allow the broken package to be reconfigured.
 	</p>
-- 




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Mon, 26 Jul 2010 22:45:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 26 Jul 2010 22:45:08 GMT) Full text and rfc822 format available.

Message #215 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 504880@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Mon, 26 Jul 2010 15:39:30 -0700
Jonathan Nieder <jrnieder@gmail.com> writes:
> Russ Allbery wrote:

>> I think we should hopefully be close to a final wording now.

> Indeed!  All I have left are copy-edits (patch below).

Thanks!  Applied to my copy.

>> @@ -5048,7 +5132,7 @@ Provides: mail-transport-agent
>>  Conflicts: mail-transport-agent
>>  Replaces: mail-transport-agent
>>  	    </example>
>> -	    ensuring that only one MTA can be installed at any one
>> +	    ensuring that only one MTA can be unpacked at any one
>>  	    time.  See <ref id="virtual"> for more information about this
>>  	    example.
>>  	</sect1>

> Aside: is this advice right?  Maybe we should be encouraging

>  Provides: mail-transport-agent
>  Breaks: mail-transport-agent
>  Replaces: mail-transport-agent

> instead.

Policy 11.6 requires that any package providing mail-transport-agent
install /usr/sbin/sendmail and provide a program called newaliases, and
hence they really do need Conflicts:

    /etc/aliases is the source file for the system mail aliases (e.g.,
    postmaster, usenet, etc.), it is the one which the sysadmin and
    postinst scripts may edit. After /etc/aliases is edited the program or
    human editing it must call newaliases. All MTA packages must come with
    a newaliases program, even if it does nothing, but older MTA packages
    did not do this so programs should not fail if newaliases cannot be
    found. Note that because of this, all MTA packages must have Provides,
    Conflicts and Replaces: mail-transport-agent control fields.

The problem with using alternatives here is that the sendmail and
newaliases programs have to match whatever MTA is actually being used,
since bad things could happen (like losing data) if the alternative points
to one MTA but a different MTA is actually running.  Alternatives don't
really provide a good way of making those things line up, so what we've
historically done is make all the mail-transport-agent providers just ship
those binaries in those paths and conflict with each other.  That prevents
installing more than one MTA at the same time, which could occasionally be
useful, but ensures that everything installed is consistent and works
together.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Mon, 26 Jul 2010 22:45:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 26 Jul 2010 22:45:09 GMT) Full text and rfc822 format available.

Message #220 received at 504880@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Mon, 26 Jul 2010 17:38:40 -0500
Russ Allbery wrote:

[...]
>                                                         (a common
>          situation when upgrading shared libraries and their
>          corresponding development packages)
[...]
> That moves the whole thing into a footnote and gives a more specific
> example.

Nice.  Thanks for the explanation.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Mon, 26 Jul 2010 23:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 26 Jul 2010 23:09:03 GMT) Full text and rfc822 format available.

Message #225 received at 504880@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: 504880@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: mail-transport-agent (Re: Bug#504880: Disambiguate "installed" for packages)
Date: Mon, 26 Jul 2010 18:05:55 -0500
Russ Allbery wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:

>> Aside: is this advice right?  Maybe we should be encouraging
>
>>  Provides: mail-transport-agent
>>  Breaks: mail-transport-agent
>>  Replaces: mail-transport-agent
>
>> instead.
[...]
> newaliases programs have to match whatever MTA is actually being used,
> since bad things could happen (like losing data) if the alternative points
> to one MTA but a different MTA is actually running.  Alternatives don't
> really provide a good way of making those things line up, so what we've
> historically done is make all the mail-transport-agent providers just ship
> those binaries in those paths and conflict with each other.

Part of the reason I am interested is because it makes switching
between MTAs difficult.  Recently[1] there was some discussion
proposing the following rule:

	Secondly, Replaces allows the packaging system to resolve which
	package should be removed when there is a conflict - see
	Conflicting binary packages - Conflicts, Section 7.4.  This
	usage only takes effect when the two packages do conflict, so
	that the two usages of this field do not interfere with each
	other.

	Conflicts+Replaces should be used only to ensure that obsolete
	packages are removed in favour of new packages.  A package
	should not declare Replaces against any non-obsolete package,
	and it should not declare Replaces against any virtual package
	it itself provides.

That /seems/ to neglect another traditional use of Conflicts+Replaces,
which is to allow switching between relatively important packages that
cannot be installed at the same time.

If we instead take the Conflicts seriously, then switching between MTAs
requires the following sequences of events:

 deconfigure packages that pre-depend or depend on mail-transport-agent
 remove the old mail-transport-agent
 unpack the new mail-transport-agent  
 configure in the appropriate order

This looks like an awfully slow way to accomplish a task that would
probably be dealt with better by triggering on /etc/aliases.  But that
is probably something to propose for squeeze+2 or so.

Thanks for the explanation.

[1] http://lists.debian.org/debian-ctte/2010/05/msg00010.html




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Mon, 26 Jul 2010 23:42:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 26 Jul 2010 23:42:06 GMT) Full text and rfc822 format available.

Message #230 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 504880@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: mail-transport-agent (Re: Bug#504880: Disambiguate "installed" for packages)
Date: Mon, 26 Jul 2010 16:39:58 -0700
Jonathan Nieder <jrnieder@gmail.com> writes:

> If we instead take the Conflicts seriously, then switching between MTAs
> requires the following sequences of events:

>  deconfigure packages that pre-depend or depend on mail-transport-agent
>  remove the old mail-transport-agent
>  unpack the new mail-transport-agent  
>  configure in the appropriate order

> This looks like an awfully slow way to accomplish a task that would
> probably be dealt with better by triggering on /etc/aliases.  But that
> is probably something to propose for squeeze+2 or so.

I think what happens in practice in this case is that apt calls dpkg with
some --force-* flag, or at least that's what the messages that I've seen
scroll by in this sort of situation seem to imply.  I agree that it would
be good to have a better way of handling it (although also agree that's a
different bug than this one).

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Tue, 27 Jul 2010 13:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 27 Jul 2010 13:15:03 GMT) Full text and rfc822 format available.

Message #235 received at 504880@bugs.debian.org (full text, mbox):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: 504880@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Tue, 27 Jul 2010 15:12:22 +0200
On Mon, Jul 26, 2010 at 03:39:30PM -0700, Russ Allbery wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
> > Russ Allbery wrote:
> 
> >> I think we should hopefully be close to a final wording now.
> 
> > Indeed!  All I have left are copy-edits (patch below).
> 
> Thanks!  Applied to my copy.
> 
> >> @@ -5048,7 +5132,7 @@ Provides: mail-transport-agent
> >>  Conflicts: mail-transport-agent
> >>  Replaces: mail-transport-agent
> >>  	    </example>
> >> -	    ensuring that only one MTA can be installed at any one
> >> +	    ensuring that only one MTA can be unpacked at any one
> >>  	    time.  See <ref id="virtual"> for more information about this
> >>  	    example.
> >>  	</sect1>
> 
> > Aside: is this advice right?  Maybe we should be encouraging
> 
> >  Provides: mail-transport-agent
> >  Breaks: mail-transport-agent
> >  Replaces: mail-transport-agent
> 
> > instead.
> 
> Policy 11.6 requires that any package providing mail-transport-agent
> install /usr/sbin/sendmail and provide a program called newaliases, and
> hence they really do need Conflicts:
> 
>     /etc/aliases is the source file for the system mail aliases (e.g.,
>     postmaster, usenet, etc.), it is the one which the sysadmin and
>     postinst scripts may edit. After /etc/aliases is edited the program or
>     human editing it must call newaliases. All MTA packages must come with
>     a newaliases program, even if it does nothing, but older MTA packages
>     did not do this so programs should not fail if newaliases cannot be
>     found. Note that because of this, all MTA packages must have Provides,
>     Conflicts and Replaces: mail-transport-agent control fields.
> 
> The problem with using alternatives here is that the sendmail and
> newaliases programs have to match whatever MTA is actually being used,
> since bad things could happen (like losing data) if the alternative points
> to one MTA but a different MTA is actually running.  Alternatives don't
> really provide a good way of making those things line up, so what we've
> historically done is make all the mail-transport-agent providers just ship
> those binaries in those paths and conflict with each other.  That prevents
> installing more than one MTA at the same time, which could occasionally be
> useful, but ensures that everything installed is consistent and works
> together.

Another issue is that only one MTA can be listening on port 25 at any time, and Debian
does not provide a way to prevent two packages to be configured to listen on the same
port.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Fri, 30 Jul 2010 12:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 30 Jul 2010 12:15:03 GMT) Full text and rfc822 format available.

Message #240 received at 504880@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: 504880@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Fri, 30 Jul 2010 14:13:31 +0200
[Message part 1 (text/plain, inline)]
On Mon, 26 Jul 2010, Russ Allbery wrote:
> Here is an updated version of the proposed patch, reflecting additional
> feedback.  I think we should hopefully be close to a final wording now.

I have reviewed the patch and did not found any problem.

Seconded.

>  	<p>
>  	  The <prgn>DEBIAN</prgn> directory will not appear in the
>  	  file system archive of the package, and so won't be installed
> -	  by <prgn>dpkg</prgn> when the package is installed.
> +	  by <prgn>dpkg</prgn> when the package is unpacked.
>  	</p>

Technically, it's unpacked: not in /DEBIAN but in /var/lib/dpkg/tmp.ci/
and then moved to /var/lib/dpkg/info/package.* at the end of the unpack
phase but it's probably not worth pointing out in policy (or only as a
footnote).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Wed, 04 Aug 2010 20:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 04 Aug 2010 20:18:04 GMT) Full text and rfc822 format available.

Message #245 received at 504880@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Wed, 4 Aug 2010 16:16:08 -0400
[Message part 1 (text/plain, inline)]
On Wed, Jul 21, 2010 at 01:52:50PM -0700, Russ Allbery wrote:
> diff --git a/policy.sgml b/policy.sgml
> index 847f716..eb458fe 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -1079,10 +1079,10 @@
>  	</p>
>  
>  	<p>
> -	  Sometimes, a package requires another package to be installed
> -	  <em>and</em> configured before it can be installed. In this
> -	  case, you must specify a <tt>Pre-Depends</tt> entry for
> -	  the package.
> +	  Sometimes, a package requires another package to be unpacked
> +	  <em>and</em> configured before it can be unpacked.  In this
> +	  case, the dependent package must specify this dependency in
> +	  the <tt>Pre-Depends</tt> control field.
>  	</p>
>  
>  	<p>

I think "depending package" is clearer than "dependent package", since
there's less possibility of confusion with "dependency".  (The usage
"dependent package" does not currently exist elsewhere in Policy.)

> +	      The package will not yet be unpacked, so
> +	      the <prgn>preinst</prgn> script cannot rely on any files
> +	      included in its package.  Only essential packages and
> +	      pre-dependencies (<tt>Pre-Depends</tt>) may be assumed to be
> +	      available.  Pre-dependencies will be at least unpacked.
> +	      They may be only unpacked or "Half-Configured", not
> +	      completely configured, but only if a previous version of the
> +	      pre-dependency was completely configured and the
> +	      pre-dependency had not been removed since then.
>  	    </item>

Maybe it would be clearer to write it this way?

  Pre-dependencies will have been configured at least once, but at the time
  the preinst is called they may only be in an unpacked or "Half-Configured"
  state if a previous version of the pre-dependency was completely
  configured and has not been removed (uninstalled?) since then.

Does dpkg provide any guarantee that the dependencies of the pre-dependency
are also present at this point?  If it doesn't, I think that should be
considered a bug in dpkg, since you may be invoking a command that links
against a library whose soname has changed since the last time the pre-dep
package was configured.  If it /does/ provide this guarantee, I think it
should be documented in Policy.


> +	  The <prgn>postinst</prgn> script may be called in the following
> +	  ways:
> +	  <taglist>
> +	    <tag><var>postinst</var> <tt>configure</tt>
> +	      <var>most-recently-configured-version</var></tag>
>  	    <item>
> -		<var>conflictor's-prerm</var> <tt>remove</tt>
> -		<tt>in-favour</tt> <var>package</var>
> -		<var>new-version</var>
> +	      The files contained in the package will be unpacked.  All
> +	      package dependencies will at least be unpacked.  If there
> +	      are no circular dependencies involved, all package
> +	      dependencies will be configured.
>  	    </item>

Should this include a pointer to the section documenting the rules for
breaking circular dependencies?

> +	      unpacked in some error situations.<footnote>
> +		For example, suppose packages foo and bar are installed
> +		with foo depending on bar.  If an upgrade of bar were
> +		started and then aborted, and then an attempt to remove
> +		foo failed because its <prgn>prerm</prgn> script failed,
> +		foo's <tt>postinst abort-remove</tt> would be called with
> +		bar only "Half-Installed".
> +	      </footnote>
>  	    </item>
> -	  </list>
> +	  </taglist>
> +	</p>

This footnote is interesting to me because although it accurately documents
dpkg's behavior, I'm not sure what implications it has for how packages
should guard against this case.  I think I've always ignored this possibility
in my maintainer scripts, and will continue to do so on the grounds that any
attempt to handle this gracefully is likely to introduce much greater
complexity (and therefore bugs) with very little upside (when all is said
and done, a package you were trying to remove is still installed, so do we
care if it configures successfully?)

If we can make a straightforward recommendation to maintainers for how to
handle this case, I think we should include that in the footnote.
Otherwise, if it shouldn't affect how we write maintainer scripts, perhaps
it's better not to have this footnote at all since it would only lead to
maintainers trying to be too clever and shooting themselves in the foot?

> +	<p>
> +	  The <prgn>postrm</prgn> script may be called in the following
> +	  ways:
> +	  <taglist>
> +	    <tag><var>postrm</var> <tt>remove</tt></tag>
> +	    <tag><var>postrm</var> <tt>purge</tt></tag>
> +	    <tag><var>old-postrm</var> <tt>upgrade</tt>
> +	      <var>new-version</var></tag>
> +	    <tag><var>disappearer's-postrm</var> <tt>disappear</tt>
> +		<var>overwriter</var> <var>overwriter-version</var></tag>
>  	    <item>
> -		<var>new-postrm</var> <tt>abort-install</tt>
> -		<var>old-version</var>
> +	      The <prgn>postrm</prgn> script is called after the package's
> +	      files have been removed or replaced.  The package
> +	      whose <prgn>postrm</prgn> is being called may have
> +	      previously been deconfigured and only be unpacked, at which
> +	      point subsequent package changes do not consider its
> +	      dependencies.  Therefore, all <prgn>postrm</prgn> actions
> +	      may only rely on essential packages and cannot assume that
> +	      the package's dependencies are available.
>  	    </item>

True as written, but less helpful than it should be.  There are a number of
cases where postrm scripts still need to *try* to invoke non-essential
functionality, and fail gracefully if it's unavailable; this should be
explicitly encouraged so that maintainers don't come away thinking they
shouldn't try to clean up after themselves.

Ex.: if you have a package that manages a config file with ucf, you *must*
call ucf --purge from "postrm purge" if ucf is present on the system at this
point; failure to do so will give completely unintuitive handling of the
config file on package purge && reinstall.

Proposed wording (improvements requested):

   Therefore, all <prgn>postrm</prgn> actions may only rely on essential
   packages and must gracefully omit anything requiring the package's
   dependencies when those dependencies are unavailable.

> -	  The <tt>Depends</tt> field thus allows package maintainers
> -	  to impose an order in which packages should be configured.
> +	  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 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 <prgn>postinst</prgn>
> +	  script, then the cycle will be broken at that package; this
> +	  ensures that all <prgn>postinst</prgn> scripts are run with
> +	  their dependencies properly configured if this is possible.
> +	  Otherwise the breaking point is arbitrary.  Packages should
> +	  therefore avoid circular dependencies where possible,
> +	  particularly if they have <prgn>postinst</prgn> scripts.
>  	</p>
>  
>  	<p>

  --> Packages involved in circular dependencies may not be able to rely on
      their dependencies being configured before they themselves are
      configured, depending on which side of the break of the circular
      dependency loop they happen to be on.

> @@ -4588,12 +4651,17 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
>  
>  	      <p>
>  		The <tt>Depends</tt> field should also be used if the
> -		<prgn>postinst</prgn>, <prgn>prerm</prgn> or
> -		<prgn>postrm</prgn> scripts require the package to be
> -		present in order to run.  Note, however, that the
> -		<prgn>postrm</prgn> cannot rely on any non-essential
> -		packages to be present during the <tt>purge</tt>
> -		phase.
> +		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
> +		require the depended-on package to be unpacked or
> +		configured in order to run.  In the case of <tt>postinst
> +		configure</tt>, the depended-on packages will be unpacked
> +		and configured first.  (If both packages are involved in a
> +		dependency loop, this might not work as expected; see the
> +		explanation a few paragraphs back.)  In the case
> +		of <prgn>prerm</prgn> or other <prgn>postinst</prgn>
> +		actions, the package dependencies will be at least
> +		unpacked or "Half-Installed".
> +	      </p>
>  	    </item>

I disagree with this change.  If you are making use of non-essential
packages in your postrm, you *should* use the Depends: field; you just
*also* have to have a clean fallback plan if the dependency is not satisfied
when the postrm is called.

The normal use case is "whichever of the two packages is removed first must
clean up".  While I can't think of a case where the cleanup interface called
from the postrm isn't already a dependency for other reasons (e.g., for use
in the postinst), I'd like this to be explicit all the same.


The rest looks good to me.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Mon, 09 Aug 2010 00:33:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 09 Aug 2010 00:33:09 GMT) Full text and rfc822 format available.

Message #250 received at 504880@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: 504880@bugs.debian.org
Cc: Russ Allbery <rra@debian.org>, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 8 Aug 2010 19:27:44 -0500
Steve Langasek wrote:
> On Wed, Jul 21, 2010 at 01:52:50PM -0700, Russ Allbery wrote:

>>	                                                      In this
>> +	  case, the dependent package must specify this dependency in
>> +	  the <tt>Pre-Depends</tt> control field.
[...]
> I think "depending package" is clearer than "dependent package", since
> there's less possibility of confusion with "dependency".

Yes.  It is a case like the avoidance of “inflammable”.  Sometimes
people need an answer from policy without enough time to think about
etymology.

>> +	                  Pre-dependencies will be at least unpacked.
>> +	      They may be only unpacked or "Half-Configured", not
>> +	      completely configured, but only if a previous version of the
>> +	      pre-dependency was completely configured and the
>> +	      pre-dependency had not been removed since then.
>>  	    </item>
>
> Maybe it would be clearer to write it this way?
>
>   Pre-dependencies will have been configured at least once, but at the time
>   the preinst is called they may only be in an unpacked or "Half-Configured"
>   state if a previous version of the pre-dependency was completely
>   configured and has not been removed (uninstalled?) since then.

Your phrasing is more straightforward.

I prefer removed over uninstalled because the corresponding dpkg
action is “dpkg --remove”.  Anyway, such a change throughout policy
would be a separate topic.

> Does dpkg provide any guarantee that the dependencies of the pre-dependency
> are also present at this point?

Sure: that is part of what it means to configure a package.

Except *new* dependencies of an upgraded pre-depedency may not be
present.  This is part of the philosophy behind pseudo-essential
packages generally using pre-depends for one release when they
acquire new dependencies.

> If it doesn't, I think that should be
> considered a bug in dpkg, since you may be invoking a command that links
> against a library whose soname has changed since the last time the pre-dep
> package was configured.  If it /does/ provide this guarantee, I think it
> should be documented in Policy.

Should I file a policy bug to clarify this?

>> +	    <tag><var>postinst</var> <tt>configure</tt>
[...]
>>	                                                       If there
>> +	      are no circular dependencies involved, all package
>> +	      dependencies will be configured.
>>  	    </item>
>
> Should this include a pointer to the section documenting the rules for
> breaking circular dependencies?

Maybe something as simple as “(See also <ref id="binarydeps">)”.

>> +	      unpacked in some error situations.<footnote>
>> +		For example, suppose packages foo and bar are installed
>> +		with foo depending on bar.  If an upgrade of bar were
>> +		started and then aborted, and then an attempt to remove
>> +		foo failed because its <prgn>prerm</prgn> script failed,
>> +		foo's <tt>postinst abort-remove</tt> would be called with
>> +		bar only "Half-Installed".
>> +	      </footnote>
>>  	    </item>
>> -	  </list>
>> +	  </taglist>
>> +	</p>
>
> This footnote is interesting to me because although it accurately documents
> dpkg's behavior, I'm not sure what implications it has for how packages
> should guard against this case.

Hopefully Russ can say something useful on this.  My guess is “make
sure you error out with an appropriate message if functionality from a
dependency fails”.  That way, the recovery process can error out and
the operator can deal with the problem, for example by reinstalling
the dependency.

Instead, let me mention how rare this problem should be in practice:
the problem we are describing is that an upgrade (for a dependency)
can be interrupted in the middle of unpacking.

dpkg unpacks in three stages: first it writes some temporary files,
then a storm of renames, then deletion of removed files.  The
problem we are describing is that the renames (or deletions) can be
interrupted in the middle.

The impact is that some files might be from the old version and others
from the new version of the dependency.  As luck has it, most packages
still Just Work™ in this scenario.

> If we can make a straightforward recommendation to maintainers for how to
> handle this case, I think we should include that in the footnote.
> Otherwise, if it shouldn't affect how we write maintainer scripts, perhaps
> it's better not to have this footnote at all since it would only lead to
> maintainers trying to be too clever and shooting themselves in the foot?

Maybe something to this effect:

	With luck, such a partially upgraded package would still
	work fine, but maintainer scripts should be prepared to
	report and error out on resulting errors if they occur.

If there is a way to test this automatically (an enhancement to piuparts,
maybe?), that would be ideal.

[...]
>> +	      The <prgn>postrm</prgn> script is called after the package's
>> +	      files have been removed or replaced.  The package
>> +	      whose <prgn>postrm</prgn> is being called may have
>> +	      previously been deconfigured and only be unpacked, at which
>> +	      point subsequent package changes do not consider its
>> +	      dependencies.
[...]
> True as written, but less helpful than it should be.  There are a number of
> cases where postrm scripts still need to *try* to invoke non-essential
> functionality, and fail gracefully if it's unavailable

Yes, that is worth mentioning.  Actually it has very little to do with
dependencies.

For example, many packages only use “Suggests: doc-base” but have
snippets like the following in prerm:

	# Automatically added by dh_installdocs
	if [ "$1" = remove ] || [ "$1" = upgrade ] && \
	   which install-docs >/dev/null 2>&1; then
		install-docs -r whatever
	fi

Maybe a footnote would be appropriate?  Something along these lines:

	This is not intended to excuse packages from the obligation
	to clean up after themselves when they have placed some
	state in a non-essential package's care.  The usual strategy
	for that is as follows:

	If you have a package that manages a configuration file
	with ucf, you must call "ucf --purge" from postrm if ucf is
	present on the system at that point.  If ucf is not present,
	then the configuration file is in its care and will be
	removed when ucf is purged.

>   --> Packages involved in circular dependencies may not be able to rely on
>       their dependencies being configured before they themselves are
>       configured, depending on which side of the break of the circular
>       dependency loop they happen to be on.

I’ve tried to incorporate this text below.

>> @@ -4588,12 +4651,17 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
>>  
>>  	      <p>
>>  		The <tt>Depends</tt> field should also be used if the
>> -		<prgn>postinst</prgn>, <prgn>prerm</prgn> or
>> -		<prgn>postrm</prgn> scripts require the package to be
>> -		present in order to run.
>> +		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
>> +		require the depended-on package to be unpacked or
>> +		configured in order to run.
[...]
> I disagree with this change.
[...]
> The normal use case is "whichever of the two packages is removed first must
> clean up".  While I can't think of a case where the cleanup interface called
> from the postrm isn't already a dependency for other reasons (e.g., for use
> in the postinst), I'd like this to be explicit all the same.

Given the explanation above, do you still think Depends should be used
this way?

> The rest looks good to me.

Thanks for the review.  Suggested changes follow; thoughts welcome.
-- 8< --
Subject: Further improvements to maintainer script state requirements
    
Based on feedback from Steve Langasek.
---
Should be applicable to bug504880-rra with “git am -i --scissors”.

diff --git a/policy.sgml b/policy.sgml
index 20c0c84..9bfb652 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1081,7 +1081,7 @@
 	<p>
 	  Sometimes, unpacking one package requires that another package
 	  be first unpacked <em>and</em> configured.  In this case, the
-	  dependent package must specify this dependency in
+	  depending package must specify this dependency in
 	  the <tt>Pre-Depends</tt> control field.
 	</p>
 
@@ -3791,11 +3791,11 @@ Checksums-Sha256:
 	      the <prgn>preinst</prgn> script cannot rely on any files
 	      included in its package.  Only essential packages and
 	      pre-dependencies (<tt>Pre-Depends</tt>) may be assumed to be
-	      available.  Pre-dependencies will be at least unpacked.
-	      They may be only unpacked or "Half-Configured", not
-	      completely configured, but only if a previous version of the
-	      pre-dependency was completely configured and the
-	      pre-dependency had not been removed since then.
+	      available.  Pre-dependencies will have been configured at
+	      least once, but at the time the <prgn>preinst</prgn> script
+	      is called, they may only be in an unpacked or "Half-Configured"
+	      state if a previous version of the pre-dependency was
+	      completely configured and has not been removed since then.
 	    </item>
 
 	    <tag><var>old-preinst</var> <tt>abort-upgrade</tt>
@@ -3829,6 +3829,7 @@ Checksums-Sha256:
 	      package dependencies will at least be unpacked.  If there
 	      are no circular dependencies involved, all package
 	      dependencies will be configured.
+	      (See also <ref id="binarydeps">.)
 	    </item>
 
 	    <tag><var>old-postinst</var> <tt>abort-upgrade</tt>
@@ -3848,12 +3849,20 @@ Checksums-Sha256:
 	      will have previously been configured and not removed.
 	      However, dependencies may not be configured or even fully
 	      unpacked in some error situations.<footnote>
-		For example, suppose packages foo and bar are installed
-		with foo depending on bar.  If an upgrade of bar were
-		started and then aborted, and then an attempt to remove
-		foo failed because its <prgn>prerm</prgn> script failed,
-		foo's <tt>postinst abort-remove</tt> would be called with
-		bar only "Half-Installed".
+	        <p>
+		  For example, suppose packages foo and bar are installed
+		  with foo depending on bar.  If an upgrade of bar were
+		  started and then aborted, and then an attempt to remove
+		  foo failed because its <prgn>prerm</prgn> script failed,
+		  foo's <tt>postinst abort-remove</tt> would be called with
+		  bar only "Half-Installed".
+		</p>
+
+		<p>
+		  With luck, the partially upgraded dependency would still
+		  work fine, but <prgn>postinst</prgn> should be prepared to
+		  report and error out on resulting errors when they occur.
+		</p>
 	      </footnote>
 	    </item>
 	  </taglist>
@@ -3911,7 +3920,21 @@ Checksums-Sha256:
 	      point subsequent package changes do not consider its
 	      dependencies.  Therefore, all <prgn>postrm</prgn> actions
 	      may only rely on essential packages and cannot assume that
-	      the package's dependencies are available.
+	      the package's dependencies are available.<footnote>
+		<p>
+		  This is not intended to excuse packages from the
+		  obligation to clean up after themselves when they have
+		  placed some state in a non-essential package's care.
+		  The usual strategy for that is as follows:
+		</p>
+		<p>
+		  If you have a package that manages a configuration file
+		  with ucf, you must call "ucf --purge" from postrm if
+		  ucf is present on the system at that point.
+		  If ucf is not present, then the configuration file is
+		  in its care and will be removed when ucf is purged.
+		</p>
+	      </footnote>
 	    </item>
 
 	    <tag><var>new-postrm</var> <tt>failed-upgrade</tt>
@@ -4645,9 +4668,16 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	  script, then the cycle will be broken at that package; this
 	  ensures that all <prgn>postinst</prgn> scripts are run with
 	  their dependencies properly configured if this is possible.
-	  Otherwise the breaking point is arbitrary.  Packages should
-	  therefore avoid circular dependencies where possible,
-	  particularly if they have <prgn>postinst</prgn> scripts.
+	  Otherwise the breaking point is arbitrary.
+	</p>
+
+	<p>
+	  Packages involved in circular dependencies may not be able to rely
+	  on their dependencies being configured before they themselves are
+	  configured, depending on which side of the break of the circular
+	  dependency loop they happen to be on.
+	  Packages should therefore avoid circular dependencies where
+	  possible, particularly if they have <prgn>postinst</prgn> scripts.
 	</p>
 
 	<p>
-- 




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sun, 15 Aug 2010 18:57:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 15 Aug 2010 18:57:06 GMT) Full text and rfc822 format available.

Message #255 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 504880@bugs.debian.org
Cc: debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 15 Aug 2010 11:53:44 -0700
Raphael Hertzog <hertzog@debian.org> writes:
> On Mon, 26 Jul 2010, Russ Allbery wrote:

>>  	<p>
>>  	  The <prgn>DEBIAN</prgn> directory will not appear in the
>>  	  file system archive of the package, and so won't be installed
>> -	  by <prgn>dpkg</prgn> when the package is installed.
>> +	  by <prgn>dpkg</prgn> when the package is unpacked.
>>  	</p>

> Technically, it's unpacked: not in /DEBIAN but in /var/lib/dpkg/tmp.ci/
> and then moved to /var/lib/dpkg/info/package.* at the end of the unpack
> phase but it's probably not worth pointing out in policy (or only as a
> footnote).

Is this true of all files in the control.tar.gz other than DEBIAN/control,
even ones unknown to dpkg?  Or does dpkg have an enumerated list of files
that it does this with?  It does seem like it would be worth documenting
/var/lib/dpkg/info somewhere non-normative.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sun, 15 Aug 2010 19:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 15 Aug 2010 19:27:03 GMT) Full text and rfc822 format available.

Message #260 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 504880@bugs.debian.org
Cc: Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 15 Aug 2010 12:25:19 -0700
Steve Langasek <vorlon@debian.org> writes:
> On Wed, Jul 21, 2010 at 01:52:50PM -0700, Russ Allbery wrote:

>> +	  Sometimes, a package requires another package to be unpacked
>> +	  <em>and</em> configured before it can be unpacked.  In this
>> +	  case, the dependent package must specify this dependency in
>> +	  the <tt>Pre-Depends</tt> control field.

> I think "depending package" is clearer than "dependent package", since
> there's less possibility of confusion with "dependency".  (The usage
> "dependent package" does not currently exist elsewhere in Policy.)

Changed.

>> +	      The package will not yet be unpacked, so
>> +	      the <prgn>preinst</prgn> script cannot rely on any files
>> +	      included in its package.  Only essential packages and
>> +	      pre-dependencies (<tt>Pre-Depends</tt>) may be assumed to be
>> +	      available.  Pre-dependencies will be at least unpacked.
>> +	      They may be only unpacked or "Half-Configured", not
>> +	      completely configured, but only if a previous version of the
>> +	      pre-dependency was completely configured and the
>> +	      pre-dependency had not been removed since then.
>>  	    </item>

> Maybe it would be clearer to write it this way?

>   Pre-dependencies will have been configured at least once, but at the
>   time the preinst is called they may only be in an unpacked or
>   "Half-Configured" state if a previous version of the pre-dependency
>   was completely configured and has not been removed (uninstalled?)
>   since then.

Yeah, that looks good to me.  Changed.

> Does dpkg provide any guarantee that the dependencies of the
> pre-dependency are also present at this point?  If it doesn't, I think
> that should be considered a bug in dpkg, since you may be invoking a
> command that links against a library whose soname has changed since the
> last time the pre-dep package was configured.  If it /does/ provide this
> guarantee, I think it should be documented in Policy.

I believe they can be in the same state as the pre-dependency itself for
exactly the same reasons, no?  Upgrades don't require deconfiguring
packages that depend on the package being upgraded, so if you abort in the
middle of upgrading a package the pre-dependency depends on, the
pre-dependency is still present and configured on the system, so dpkg will
treat the pre-dependency as satisfied.

I've not changed any wording in this area for this bug.

>> +	      The files contained in the package will be unpacked.  All
>> +	      package dependencies will at least be unpacked.  If there
>> +	      are no circular dependencies involved, all package
>> +	      dependencies will be configured.
>>  	    </item>

> Should this include a pointer to the section documenting the rules for
> breaking circular dependencies?

Added a reference.

>> +	      unpacked in some error situations.<footnote>
>> +		For example, suppose packages foo and bar are installed
>> +		with foo depending on bar.  If an upgrade of bar were
>> +		started and then aborted, and then an attempt to remove
>> +		foo failed because its <prgn>prerm</prgn> script failed,
>> +		foo's <tt>postinst abort-remove</tt> would be called with
>> +		bar only "Half-Installed".
>> +	      </footnote>
>>  	    </item>
>> -	  </list>
>> +	  </taglist>
>> +	</p>

> This footnote is interesting to me because although it accurately
> documents dpkg's behavior, I'm not sure what implications it has for how
> packages should guard against this case.  I think I've always ignored
> this possibility in my maintainer scripts, and will continue to do so on
> the grounds that any attempt to handle this gracefully is likely to
> introduce much greater complexity (and therefore bugs) with very little
> upside (when all is said and done, a package you were trying to remove
> is still installed, so do we care if it configures successfully?)

> If we can make a straightforward recommendation to maintainers for how
> to handle this case, I think we should include that in the footnote.
> Otherwise, if it shouldn't affect how we write maintainer scripts,
> perhaps it's better not to have this footnote at all since it would only
> lead to maintainers trying to be too clever and shooting themselves in
> the foot?

I think we should put it in the main text.  I've now added, after the
footnote and in the main text:

	      The <prgn>postinst</prgn> should still attempt any actions
	      for which its dependencies are required, since they will
	      normally be available, but consider the correct error
	      handling approach if those actions fail.  Aborting
	      the <prgn>postinst</prgn> action if commands or facilities
	      from the package dependencies are not available is often the
	      best approach.

which I think is roughly what you're doing and what most people are doing
and which I think is the generally best approach.

>> +	      The <prgn>postrm</prgn> script is called after the package's
>> +	      files have been removed or replaced.  The package
>> +	      whose <prgn>postrm</prgn> is being called may have
>> +	      previously been deconfigured and only be unpacked, at which
>> +	      point subsequent package changes do not consider its
>> +	      dependencies.  Therefore, all <prgn>postrm</prgn> actions
>> +	      may only rely on essential packages and cannot assume that
>> +	      the package's dependencies are available.

> True as written, but less helpful than it should be.  There are a number
> of cases where postrm scripts still need to *try* to invoke
> non-essential functionality, and fail gracefully if it's unavailable;
> this should be explicitly encouraged so that maintainers don't come away
> thinking they shouldn't try to clean up after themselves.

> Ex.: if you have a package that manages a config file with ucf, you
> *must* call ucf --purge from "postrm purge" if ucf is present on the
> system at this point; failure to do so will give completely unintuitive
> handling of the config file on package purge && reinstall.

> Proposed wording (improvements requested):

>    Therefore, all <prgn>postrm</prgn> actions may only rely on essential
>    packages and must gracefully omit anything requiring the package's
>    dependencies when those dependencies are unavailable.

I now have, as the end of this paragraph:

              Therefore, all <prgn>postrm</prgn> actions
	      may only rely on essential packages and must gracefully skip
	      any actions that require the package's dependencies if those
	      dependencies are unavailable.<footnote>
		This is often done by checking whether the command or
	        facility the <prgn>postrm</prgn> intends to call is
	        available before calling it.  For example:
<example>
if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then
        . /usr/share/debconf/confmodule
        db_purge
fi
</example>
		in <prgn>postrm</prgn> purges the <prgn>debconf</prgn>
		configuration for the package
		if <package>debconf</package> is installed.
	      </foonote>

>   --> Packages involved in circular dependencies may not be able to rely on
>       their dependencies being configured before they themselves are
>       configured, depending on which side of the break of the circular
>       dependency loop they happen to be on.

Fixed.

>>  	      <p>
>>  		The <tt>Depends</tt> field should also be used if the
>> -		<prgn>postinst</prgn>, <prgn>prerm</prgn> or
>> -		<prgn>postrm</prgn> scripts require the package to be
>> -		present in order to run.  Note, however, that the
>> -		<prgn>postrm</prgn> cannot rely on any non-essential
>> -		packages to be present during the <tt>purge</tt>
>> -		phase.
>> +		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
>> +		require the depended-on package to be unpacked or
>> +		configured in order to run.  In the case of <tt>postinst
>> +		configure</tt>, the depended-on packages will be unpacked
>> +		and configured first.  (If both packages are involved in a
>> +		dependency loop, this might not work as expected; see the
>> +		explanation a few paragraphs back.)  In the case
>> +		of <prgn>prerm</prgn> or other <prgn>postinst</prgn>
>> +		actions, the package dependencies will be at least
>> +		unpacked or "Half-Installed".
>> +	      </p>
>>  	    </item>

> I disagree with this change.  If you are making use of non-essential
> packages in your postrm, you *should* use the Depends: field; you just
> *also* have to have a clean fallback plan if the dependency is not
> satisfied when the postrm is called.

> The normal use case is "whichever of the two packages is removed first
> must clean up".  While I can't think of a case where the cleanup
> interface called from the postrm isn't already a dependency for other
> reasons (e.g., for use in the postinst), I'd like this to be explicit
> all the same.

How about this?

	      <p>
		The <tt>Depends</tt> field should also be used if the
		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
		require the depended-on package to be unpacked or
		configured in order to run, or if the dependend-on package
		is desirable for cleanup done by <prgn>postrm</prgn>.  In
		the case of <tt>postinst configure</tt>, the depended-on
		packages will be unpacked and configured first.  (If both
		packages are involved in a dependency loop, this might not
		work as expected; see the explanation a few paragraphs
		back.)  In the case of <prgn>prerm</prgn> or
		other <prgn>postinst</prgn> actions, the package
		dependencies will normally be at least unpacked, but they
		may be only "Half-Installed" if a previous upgrade of the
		dependency failed.  In the case of <prgn>postrm</prgn>,
		there are no guarantees, but the depended-on package is
		more likely to be available if the package declares a
		dependency (particularly for <tt>postrm remove</tt>).
		The <prgn>postrm</prgn> script must cleanly skip actions
		that require a dependency if that dependency isn't
		available.
	      </p>

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sun, 15 Aug 2010 19:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 15 Aug 2010 19:33:03 GMT) Full text and rfc822 format available.

Message #265 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 504880@bugs.debian.org
Cc: Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 15 Aug 2010 12:29:37 -0700
Here's the new version of the patch.

diff --git a/policy.sgml b/policy.sgml
index 0624290..8a70ebf 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1104,10 +1104,10 @@
 	</p>
 
 	<p>
-	  Sometimes, a package requires another package to be installed
-	  <em>and</em> configured before it can be installed. In this
-	  case, you must specify a <tt>Pre-Depends</tt> entry for
-	  the package.
+	  Sometimes, unpacking one package requires that another package
+	  be first unpacked <em>and</em> configured.  In this case, the
+	  depending package must specify this dependency in
+	  the <tt>Pre-Depends</tt> control field.
 	</p>
 
 	<p>
@@ -3727,7 +3727,7 @@ Checksums-Sha256:
 
 	<p>
 	  Broadly speaking the <prgn>preinst</prgn> is called before
-	  (a particular version of) a package is installed, and the
+	  (a particular version of) a package is unpacked, and the
 	  <prgn>postinst</prgn> afterwards; the <prgn>prerm</prgn>
 	  before (a version of) a package is removed and the
 	  <prgn>postrm</prgn> afterwards.
@@ -3811,111 +3811,200 @@ Checksums-Sha256:
 	</heading>
 
 	<p>
-	  <list compact="compact">
-	    <item>
-	      <var>new-preinst</var> <tt>install</tt>
-	    </item>
-	    <item>
-	      <var>new-preinst</var> <tt>install</tt> <var>old-version</var>
-	    </item>
-	    <item>
-		<var>new-preinst</var> <tt>upgrade</tt> <var>old-version</var>
-	    </item>
-	    <item>
-		<var>old-preinst</var> <tt>abort-upgrade</tt>
-		<var>new-version</var>
-	    </item>
-	  </list>
+	  What follows is a summary of all the ways in which maintainer
+	  scripts may be called along with what facilities those scripts
+	  may rely on being available at that time.  Script names preceded
+	  by <var>new-</var> are the scripts from the new version of a
+	  package being installed, upgraded to, or downgraded to.  Script
+	  names preceded by <var>old-</var> are the scripts from the old
+	  version of a package that is being upgraded from or downgraded
+	  from.
+	</p>
 
 	<p>
-	  <list compact="compact">
-	    <item>
-		<var>postinst</var> <tt>configure</tt>
-		<var>most-recently-configured-version</var>
-	    </item>
-	    <item>
-		<var>old-postinst</var> <tt>abort-upgrade</tt>
-		<var>new-version</var>
-	    </item>
-	    <item>
-		<var>conflictor's-postinst</var> <tt>abort-remove</tt>
-		<tt>in-favour</tt> <var>package</var>
-		<var>new-version</var>
-	    </item>
+	  The <prgn>preinst</prgn> script may be called in the following
+	  ways:
+	  <taglist>
+	    <tag><var>new-preinst</var> <tt>install</tt></tag>
+	    <tag><var>new-preinst</var> <tt>install</tt>
+	      <var>old-version</var></tag>
+	    <tag><var>new-preinst</var> <tt>upgrade</tt>
+	      <var>old-version</var></tag>
 	    <item>
-		<var>postinst</var> <tt>abort-remove</tt>
+	      The package will not yet be unpacked, so
+	      the <prgn>preinst</prgn> script cannot rely on any files
+	      included in its package.  Only essential packages and
+	      pre-dependencies (<tt>Pre-Depends</tt>) may be assumed to be
+	      available.  Pre-dependencies will have been configured at
+	      least once, but at the time the <prgn>preinst</prgn> is
+	      called they may only be in an unpacked or "Half-Configured"
+	      state if a previous version of the pre-dependency was
+	      completely configured and has not been removed since then.
 	    </item>
+
+	    <tag><var>old-preinst</var> <tt>abort-upgrade</tt>
+	      <var>new-version</var></tag>
 	    <item>
-		<var>deconfigured's-postinst</var>
-		<tt>abort-deconfigure</tt> <tt>in-favour</tt>
-		<var>failed-install-package</var> <var>version</var>
-		[<tt>removing</tt> <var>conflicting-package</var>
-		<var>version</var>]
+	      Called during error handling of an upgrade that failed after
+	      unpacking the new package because the <tt>postrm
+	      upgrade</tt> action failed.  The unpacked files may be
+	      partly from the new version or partly missing, so the script
+	      cannot rely on files included in the package.  Package
+	      dependencies may not be available.  Pre-dependencies will be
+	      at least unpacked following the same rules as above, except
+	      they may be only "Half-Installed" if an upgrade of the
+	      pre-dependency failed.<footnote>
+		This can happen if the new version of the package no
+		longer pre-depends on a package that had been partially
+		upgraded.
+	      </footnote>
 	    </item>
-	  </list>
+	  </taglist>
+	</p>
 
 	<p>
-	  <list compact="compact">
-	    <item>
-		<var>prerm</var> <tt>remove</tt>
-	    </item>
-	    <item>
-		<var>old-prerm</var> <tt>upgrade</tt>
-		<var>new-version</var>
-	    </item>
-	    <item>
-		<var>new-prerm</var> <tt>failed-upgrade</tt>
-		<var>old-version</var>
-	    </item>
+	  The <prgn>postinst</prgn> script may be called in the following
+	  ways:
+	  <taglist>
+	    <tag><var>postinst</var> <tt>configure</tt>
+	      <var>most-recently-configured-version</var></tag>
 	    <item>
-		<var>conflictor's-prerm</var> <tt>remove</tt>
-		<tt>in-favour</tt> <var>package</var>
-		<var>new-version</var>
+	      The files contained in the package will be unpacked.  All
+	      package dependencies will at least be unpacked.  If there
+	      are no circular dependencies involved, all package
+	      dependencies will be configured.  For behavior in the case
+	      of circular dependencies, see the discussion
+	      in <ref id="binarydeps">.
 	    </item>
+
+	    <tag><var>old-postinst</var> <tt>abort-upgrade</tt>
+	      <var>new-version</var></tag>
+	    <tag><var>conflictor's-postinst</var> <tt>abort-remove</tt>
+	      <tt>in-favour</tt> <var>package</var>
+	      <var>new-version</var></tag>
+	    <tag><var>postinst</var> <tt>abort-remove</tt></tag>
+	    <tag><var>deconfigured's-postinst</var>
+	      <tt>abort-deconfigure</tt> <tt>in-favour</tt>
+	      <var>failed-install-package</var> <var>version</var>
+	      [<tt>removing</tt> <var>conflicting-package</var>
+	      <var>version</var>]</tag>
 	    <item>
-		<var>deconfigured's-prerm</var> <tt>deconfigure</tt>
-		<tt>in-favour</tt> <var>package-being-installed</var>
-		<var>version</var> [<tt>removing</tt>
-		<var>conflicting-package</var>
-		<var>version</var>]
+	      The files contained in the package will be unpacked.  All
+	      package dependencies will at least be "Half-Installed" and
+	      will have previously been configured and not removed.
+	      However, dependencies may not be configured or even fully
+	      unpacked in some error situations.<footnote>
+		For example, suppose packages foo and bar are installed
+		with foo depending on bar.  If an upgrade of bar were
+		started and then aborted, and then an attempt to remove
+		foo failed because its <prgn>prerm</prgn> script failed,
+		foo's <tt>postinst abort-remove</tt> would be called with
+		bar only "Half-Installed".
+	      </footnote>
+	      The <prgn>postinst</prgn> should still attempt any actions
+	      for which its dependencies are required, since they will
+	      normally be available, but consider the correct error
+	      handling approach if those actions fail.  Aborting
+	      the <prgn>postinst</prgn> action if commands or facilities
+	      from the package dependencies are not available is often the
+	      best approach.
 	    </item>
-	  </list>
+	  </taglist>
+	</p>
 
 	<p>
-	  <list compact="compact">
-	    <item>
-		<var>postrm</var> <tt>remove</tt>
-	    </item>
-	    <item>
-		<var>postrm</var> <tt>purge</tt>
-	    </item>
-	    <item>
-		<var>old-postrm</var> <tt>upgrade</tt>
-		<var>new-version</var>
-	    </item>
+	  The <prgn>prerm</prgn> script may be called in the following
+	  ways:
+	  <taglist>
+	    <tag><var>prerm</var> <tt>remove</tt></tag>
+	    <tag><var>old-prerm</var>
+	      <tt>upgrade</tt><var>new-version</var></tag>
+	    <tag><var>conflictor's-prerm</var> <tt>remove</tt>
+	      <tt>in-favour</tt> <var>package</var>
+	      <var>new-version</var></tag>
+	    <tag><var>deconfigured's-prerm</var> <tt>deconfigure</tt>
+	      <tt>in-favour</tt> <var>package-being-installed</var>
+	      <var>version</var> [<tt>removing</tt>
+	      <var>conflicting-package</var> <var>version</var>]</tag>
 	    <item>
-		<var>new-postrm</var> <tt>failed-upgrade</tt>
-		<var>old-version</var>
+	      The package whose <prgn>prerm</prgn> is being called will be
+	      at least "Half-Installed".  All package dependencies will at
+	      least be "Half-Installed" and will have previously been
+	      configured and not removed.  If there was no error, all
+	      dependencies will at least be unpacked, but these actions
+	      may be called in various error states where dependencies are
+	      only "Half-Installed" due to a partial upgrade.
 	    </item>
+
+	    <tag><var>new-prerm</var> <tt>failed-upgrade</tt>
+	      <var>old-version</var></tag>
 	    <item>
-		<var>new-postrm</var> <tt>abort-install</tt>
+	      Called during error handling when <tt>prerm upgrade</tt>
+	      fails.  The new package will not yet be unpacked, and all
+	      the same constraints as for <tt>preinst upgrade</tt> apply.
 	    </item>
+	  </taglist>
+	</p>
+
+	<p>
+	  The <prgn>postrm</prgn> script may be called in the following
+	  ways:
+	  <taglist>
+	    <tag><var>postrm</var> <tt>remove</tt></tag>
+	    <tag><var>postrm</var> <tt>purge</tt></tag>
+	    <tag><var>old-postrm</var> <tt>upgrade</tt>
+	      <var>new-version</var></tag>
+	    <tag><var>disappearer's-postrm</var> <tt>disappear</tt>
+		<var>overwriter</var> <var>overwriter-version</var></tag>
 	    <item>
-		<var>new-postrm</var> <tt>abort-install</tt>
-		<var>old-version</var>
+	      The <prgn>postrm</prgn> script is called after the package's
+	      files have been removed or replaced.  The package
+	      whose <prgn>postrm</prgn> is being called may have
+	      previously been deconfigured and only be unpacked, at which
+	      point subsequent package changes do not consider its
+	      dependencies.  Therefore, all <prgn>postrm</prgn> actions
+	      may only rely on essential packages and must gracefully skip
+	      any actions that require the package's dependencies if those
+	      dependencies are unavailable.<footnote>
+		This is often done by checking whether the command or
+	        facility the <prgn>postrm</prgn> intends to call is
+	        available before calling it.  For example:
+<example>
+if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then
+        . /usr/share/debconf/confmodule
+        db_purge
+fi
+</example>
+		in <prgn>postrm</prgn> purges the <prgn>debconf</prgn>
+		configuration for the package
+		if <package>debconf</package> is installed.
+	      </foonote>
 	    </item>
+
+	    <tag><var>new-postrm</var> <tt>failed-upgrade</tt>
+	      <var>old-version</var></tag>
 	    <item>
-		<var>new-postrm</var> <tt>abort-upgrade</tt>
-		<var>old-version</var>
+	      Called when the old <tt>postrm upgrade</tt> action fails.
+	      The new package will be unpacked, but only essential
+	      packages and pre-dependencies can be relied on.
+	      Pre-dependencies will either be configured or will be
+	      "Unpacked" or "Half-Configured" but previously had been
+	      configured and was never removed.
 	    </item>
+
+	    <tag><var>new-postrm</var> <tt>abort-install</tt></tag>
+	    <tag><var>new-postrm</var> <tt>abort-install</tt>
+	      <var>old-version</var></tag>
+	    <tag><var>new-postrm</var> <tt>abort-upgrade</tt>
+	      <var>old-version</var></tag>
 	    <item>
-		<var>disappearer's-postrm</var> <tt>disappear</tt>
-		<var>overwriter</var>
-		<var>overwriter-version</var>
+	      Called before unpacking the new package as part of the
+	      error handling of <prgn>preinst</prgn> failures.  May assume
+	      the same state as <prgn>preinst</prgn> can assume.
 	    </item>
-	  </list>
+	  </taglist>
 	</p>
-
+      </sect>
 
       <sect id="unpackphase">
 	<heading>Details of unpack phase of installation or upgrade</heading>
@@ -4117,7 +4206,7 @@ Checksums-Sha256:
 		behavior which, though deterministic, is hard for the
 		system administrator to understand.  It can easily
 		lead to "missing" programs if, for example, a package
-		is installed which overwrites a file from another
+		is unpacked which overwrites a file from another
 		package, and is then removed again.<footnote>
 		    Part of the problem is due to what is arguably a
 		    bug in <prgn>dpkg</prgn>.
@@ -4253,7 +4342,7 @@ Checksums-Sha256:
 		If there was a conflicting package we go and do the
 		removal actions (described below), starting with the
 		removal of the conflicting package's files (any that
-		are also in the package being installed have already
+		are also in the package being unpacked have already
 		been removed from the conflicting package's file list,
 		and so do not get removed now).
 	    </item>
@@ -4593,31 +4682,40 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	</p>
 
 	<p>
-	  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.
+	  Since <tt>Depends</tt> only places requirements on the order in
+	  which packages are configured, packages in an installation run
+	  are usually all unpacked first and all configured later.
+	  <footnote>
+	    This approach makes dependency resolution easier.  If two
+	    packages A and B are being upgraded, the installed package A
+	    depends on exactly the installed package B, and the new
+	    package A depends on exactly the new package B (a common
+	    situation when upgrading shared libraries and their
+	    corresponding development packages), satisfying the
+	    dependencies at every stage of the upgrade would be
+	    impossible.  This relaxed restriction means that both new
+	    packages can be unpacked together and then configured in their
+	    dependency order.
+	  </footnote>
 	</p>
 
-        <p>
-          In case of circular dependencies, since installation or
-          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
-          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
-          all postinst scripts run with the dependencies properly
-          configured if this is possible. Otherwise the breaking point
-          is arbitrary.
-        </p>
-
 	<p>
-	  The <tt>Depends</tt> field thus allows package maintainers
-	  to impose an order in which packages should be configured.
+	  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 before they themselves are configured, 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 <prgn>postinst</prgn> script, then the cycle will be broken
+	  at that package; this ensures that all <prgn>postinst</prgn>
+	  scripts are run with their dependencies properly configured if
+	  this is possible.  Otherwise the breaking point is arbitrary.
+	  Packages should therefore avoid circular dependencies where
+	  possible, particularly if they have <prgn>postinst</prgn>
+	  scripts.
 	</p>
 
 	<p>
@@ -4629,7 +4727,8 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 		This declares an absolute dependency.  A package will
 		not be configured unless all of the packages listed in
 		its <tt>Depends</tt> field have been correctly
-		configured.
+		configured (unless there is a circular dependency as
+		described above).
 	      </p>
 
 	      <p>
@@ -4641,12 +4740,26 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 
 	      <p>
 		The <tt>Depends</tt> field should also be used if the
-		<prgn>postinst</prgn>, <prgn>prerm</prgn> or
-		<prgn>postrm</prgn> scripts require the package to be
-		present in order to run.  Note, however, that the
-		<prgn>postrm</prgn> cannot rely on any non-essential
-		packages to be present during the <tt>purge</tt>
-		phase.
+		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
+		require the depended-on package to be unpacked or
+		configured in order to run, or if the dependend-on package
+		is desirable for cleanup done by <prgn>postrm</prgn>.  In
+		the case of <tt>postinst configure</tt>, the depended-on
+		packages will be unpacked and configured first.  (If both
+		packages are involved in a dependency loop, this might not
+		work as expected; see the explanation a few paragraphs
+		back.)  In the case of <prgn>prerm</prgn> or
+		other <prgn>postinst</prgn> actions, the package
+		dependencies will normally be at least unpacked, but they
+		may be only "Half-Installed" if a previous upgrade of the
+		dependency failed.  In the case of <prgn>postrm</prgn>,
+		there are no guarantees, but the depended-on package is
+		more likely to be available if the package declares a
+		dependency (particularly for <tt>postrm remove</tt>).
+		The <prgn>postrm</prgn> script must cleanly skip actions
+		that require a dependency if that dependency isn't
+		available.
+	      </p>
 	    </item>
 
 	    <tag><tt>Recommends</tt></tag>
@@ -4705,11 +4818,21 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	      </p>
 
 	      <p>
-		When the package declaring a pre-dependency is about
-		to be <em>configured</em>, the pre-dependency will be
-		treated as a normal <tt>Depends</tt>, that is, it will
-		be considered satisfied only if the depended-on
-		package has been correctly configured.
+		When the package declaring a pre-dependency is about to
+		be <em>configured</em>, the pre-dependency will be treated
+		as a normal <tt>Depends</tt>.  It will be considered
+		satisfied only if the depended-on package has been
+		correctly configured.  However, unlike
+		with <tt>Depends</tt>, <tt>Pre-Depends</tt> does not
+		permit circular dependencies to be broken.  If a circular
+		dependency is encountered while attempting to honor
+		<tt>Pre-Depends</tt>, the installation will be aborted.
+	      </p>
+
+	      <p>
+		<tt>Pre-Depends</tt> are also required if the
+		<prgn>preinst</prgn> script depends on the named package.
+		It is best to avoid this situation if possible.
 	      </p>
 
 	      <p>
@@ -4718,13 +4841,6 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 		installation would hamper the ability of the system to
 		continue with any upgrade that might be in progress.
 	      </p>
-
-	      <p>
-		<tt>Pre-Depends</tt> are also required if the
-		<prgn>preinst</prgn> script depends on the named
-		package.  It is best to avoid this situation if
-		possible.
-	      </p>
 	    </item>
 	  </taglist>
 	</p>
@@ -4749,7 +4865,7 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	<p>
 	  When one binary package declares that it breaks another,
 	  <prgn>dpkg</prgn> will refuse to allow the package which
-	  declares <tt>Breaks</tt> be installed unless the broken
+	  declares <tt>Breaks</tt> to be unpacked unless the broken
 	  package is deconfigured first, and it will refuse to
 	  allow the broken package to be reconfigured.
 	</p>
@@ -4800,18 +4916,18 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	<heading>Conflicting binary packages - <tt>Conflicts</tt></heading>
 
 	<p>
-          When one binary package declares a conflict with another
-	  using a <tt>Conflicts</tt> field, <prgn>dpkg</prgn> will
-	  refuse to allow them to be installed on the system at the
-	  same time.  This is a stronger restriction than <tt>Breaks</tt>,
-	  which just prevents both packages from being configured at the
-	  same time.  Conflicting packages cannot be unpacked on the
-	  system at the same time.
+          When one binary package declares a conflict with another using
+	  a <tt>Conflicts</tt> field, <prgn>dpkg</prgn> will refuse to
+	  allow them to be unpacked on the system at the same time.  This
+	  is a stronger restriction than <tt>Breaks</tt>, which prevents
+	  the broken package from being configured while the breaking
+	  package is in the "Unpacked" state but allows both packages to
+	  be unpacked at the same time.
 	</p>
 
 	<p>
-	  If one package is to be installed, the other must be removed
-	  first.  If the package being installed is marked as replacing
+	  If one package is to be unpacked, the other must be removed
+	  first.  If the package being unpacked is marked as replacing
 	  (see <ref id="replaces">, but note that <tt>Breaks</tt> should
 	  normally be used in this case) the one on the system, or the one
 	  on the system is marked as deselected, or both packages are
@@ -4860,7 +4976,7 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
 	    <item>when two packages provide the same file and will
 	      continue to do so,</item>
 	    <item>in conjunction with <tt>Provides</tt> when only one
-	      package providing a given virtual facility may be installed
+	      package providing a given virtual facility may be unpacked
 	      at a time (see <ref id="virtual">),</item>
 	    <item>in other cases where one must prevent simultaneous
 	      installation of two packages for reasons that are ongoing
@@ -5092,7 +5208,7 @@ Provides: mail-transport-agent
 Conflicts: mail-transport-agent
 Replaces: mail-transport-agent
 	    </example>
-	    ensuring that only one MTA can be installed at any one
+	    ensuring that only one MTA can be unpacked at any one
 	    time.  See <ref id="virtual"> for more information about this
 	    example.
 	</sect1>
@@ -5391,7 +5507,7 @@ Replaces: mail-transport-agent
          <footnote>
 	    <p>
 	      During install or upgrade, the preinst is called before
-	      the new files are installed, so calling "ldconfig" is
+	      the new files are unpacked, so calling "ldconfig" is
 	      pointless.  The preinst of an existing package can also be
 	      called if an upgrade fails.  However, this happens during
 	      the critical time when a shared libs may exist on-disk
@@ -5536,7 +5652,7 @@ Replaces: mail-transport-agent
 	<ref id="conflicts">) to ensure that the user only installs one
 	development version at a time (as different development versions are
 	likely to have the same header files in them, which would cause a
-	filename clash if both were installed).
+	filename clash if both were unpacked).
       </p>
 
       <p>
@@ -9858,7 +9974,7 @@ END-INFO-DIR-ENTRY
 	<p>
 	  The <prgn>DEBIAN</prgn> directory will not appear in the
 	  file system archive of the package, and so won't be installed
-	  by <prgn>dpkg</prgn> when the package is installed.
+	  by <prgn>dpkg</prgn> when the package is unpacked.
 	</p>
 
 	<p>

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sun, 15 Aug 2010 19:45:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 15 Aug 2010 19:45:12 GMT) Full text and rfc822 format available.

Message #270 received at 504880@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: 504880@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 15 Aug 2010 21:42:59 +0200
On Sun, 15 Aug 2010, Russ Allbery wrote:
> Raphael Hertzog <hertzog@debian.org> writes:
> > On Mon, 26 Jul 2010, Russ Allbery wrote:
> 
> >>  	<p>
> >>  	  The <prgn>DEBIAN</prgn> directory will not appear in the
> >>  	  file system archive of the package, and so won't be installed
> >> -	  by <prgn>dpkg</prgn> when the package is installed.
> >> +	  by <prgn>dpkg</prgn> when the package is unpacked.
> >>  	</p>
> 
> > Technically, it's unpacked: not in /DEBIAN but in /var/lib/dpkg/tmp.ci/
> > and then moved to /var/lib/dpkg/info/package.* at the end of the unpack
> > phase but it's probably not worth pointing out in policy (or only as a
> > footnote).
> 
> Is this true of all files in the control.tar.gz other than DEBIAN/control,
> even ones unknown to dpkg?

Yes, it only has a blacklist of files that it won't install (like "list"
since it's for internal use).

The directory might be /var/lib/dpkg/info/tmp.ci/ in fact to ensure that
it's on the same filesystem and can be moved around with rename.

> It does seem like it would be worth documenting /var/lib/dpkg/info
> somewhere non-normative.

No opinion.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sun, 15 Aug 2010 20:00:15 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 15 Aug 2010 20:00:15 GMT) Full text and rfc822 format available.

Message #275 received at 504880@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 15 Aug 2010 14:57:18 -0500
Russ Allbery wrote:

> How about this?
> 
> 	      <p>
> 		The <tt>Depends</tt> field should also be used if the
> 		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
> 		require the depended-on package to be unpacked or
> 		configured in order to run, or if the dependend-on package
> 		is desirable for cleanup done by <prgn>postrm</prgn>.

I guess I am confused; when in practice is Depends better than Suggests for
this last purpose?

Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sun, 15 Aug 2010 20:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 15 Aug 2010 20:06:03 GMT) Full text and rfc822 format available.

Message #280 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 15 Aug 2010 13:03:51 -0700
Jonathan Nieder <jrnieder@gmail.com> writes:
> Russ Allbery wrote:

>> How about this?
>> 
>> 	      <p>
>> 		The <tt>Depends</tt> field should also be used if the
>> 		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
>> 		require the depended-on package to be unpacked or
>> 		configured in order to run, or if the dependend-on package
>> 		is desirable for cleanup done by <prgn>postrm</prgn>.

> I guess I am confused; when in practice is Depends better than Suggests for
> this last purpose?

When you actually want it to do something.  :)  Suggests doesn't result in
a package being installed; it's more an informational tool for high-level
package managers.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sun, 15 Aug 2010 20:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 15 Aug 2010 20:18:03 GMT) Full text and rfc822 format available.

Message #285 received at 504880@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 15 Aug 2010 15:12:58 -0500
Russ Allbery wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Russ Allbery wrote:

>>> 		The <tt>Depends</tt> field should also be used if
[...]
>>> 		                                  the dependend-on package
>>> 		is desirable for cleanup done by <prgn>postrm</prgn>.
>
>> I guess I am confused; when in practice is Depends better than Suggests for
>> this last purpose?
>
> When you actually want it to do something.  :)  Suggests doesn't result in
> a package being installed; it's more an informational tool for high-level
> package managers.

All right, Recommends then. :)

My real question was: does this ever happen in the real world?

 - doc-base already removes any remaining state when *it* is purged
 - debconf does not, but that is a bug.  In practice, debconf is
   almost never uninstalled.

My worry is that people will start depending on such packages “just in
case”.  Recommends seems better for this purpose since there are already
no guarantees.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sun, 15 Aug 2010 20:24:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 15 Aug 2010 20:24:06 GMT) Full text and rfc822 format available.

Message #290 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 15 Aug 2010 13:20:55 -0700
Jonathan Nieder <jrnieder@gmail.com> writes:

> All right, Recommends then. :)

> My real question was: does this ever happen in the real world?

>  - doc-base already removes any remaining state when *it* is purged
>  - debconf does not, but that is a bug.  In practice, debconf is
>    almost never uninstalled.

> My worry is that people will start depending on such packages “just in
> case”.  Recommends seems better for this purpose since there are already
> no guarantees.

Steve should probably respond here since he's the one who raised the
issue.  I'm not at all happy with using Recommends for this purpose, and I
suspect that the suggestion to use Recommends indicates a bug in my
wording.  Maybe I needed a stronger word than desirable?

As Steve pointed out, this is generally going to be a no-op, since if
you're cleaning something up in postrm, you probably already depended on
it because you're using it in postinst.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sun, 15 Aug 2010 20:30:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 15 Aug 2010 20:30:06 GMT) Full text and rfc822 format available.

Message #295 received at 504880@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 15 Aug 2010 15:24:59 -0500
Russ Allbery wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:

>> My real question was: does this ever happen in the real world?
>
>>  - doc-base already removes any remaining state when *it* is purged
>>  - debconf does not, but that is a bug.  In practice, debconf is
>>    almost never uninstalled.
>
>> My worry is that people will start depending on such packages “just in
>> case”.  Recommends seems better for this purpose since there are already
>> no guarantees.
>
> Steve should probably respond here since he's the one who raised the
> issue.  I'm not at all happy with using Recommends for this purpose, and I
> suspect that the suggestion to use Recommends indicates a bug in my
> wording.  Maybe I needed a stronger word than desirable?
>
> As Steve pointed out, this is generally going to be a no-op, since if
> you're cleaning something up in postrm, you probably already depended on
> it because you're using it in postinst.

Example where it is not a no-op: doc-base

In that example, neither Recommends nor Depends is appropriate, true.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sun, 15 Aug 2010 20:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 15 Aug 2010 20:39:03 GMT) Full text and rfc822 format available.

Message #300 received at 504880@bugs.debian.org (full text, mbox):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: 504880@bugs.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 15 Aug 2010 22:37:03 +0200
On Sun, Aug 15, 2010 at 02:57:18PM -0500, Jonathan Nieder wrote:
> Russ Allbery wrote:
> 
> > How about this?
> > 
> > 	      <p>
> > 		The <tt>Depends</tt> field should also be used if the
> > 		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
> > 		require the depended-on package to be unpacked or
> > 		configured in order to run, or if the dependend-on package
> > 		is desirable for cleanup done by <prgn>postrm</prgn>.
> 
> I guess I am confused; when in practice is Depends better than Suggests for
> this last purpose?

This is needed for purge: at purge time, it cannot be assumed that dependencies are installed
(hence desirable) however in the case when we purge the dependencies at the same time the
dependency is useful so that dpkg purges the packages in the right order (i.e. the dependencies
last) so that the purge can proceed. This would not work with Suggests or Recommends.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sun, 15 Aug 2010 21:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 15 Aug 2010 21:18:03 GMT) Full text and rfc822 format available.

Message #305 received at 504880@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 504880@bugs.debian.org, Russ Allbery <rra@debian.org>, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 15 Aug 2010 14:16:37 -0700
Hi Jonathan,

On Sun, Aug 08, 2010 at 07:27:44PM -0500, Jonathan Nieder wrote:
> > Does dpkg provide any guarantee that the dependencies of the pre-dependency
> > are also present at this point?

> Sure: that is part of what it means to configure a package.

> Except *new* dependencies of an upgraded pre-depedency may not be
> present.  This is part of the philosophy behind pseudo-essential
> packages generally using pre-depends for one release when they
> acquire new dependencies.

> > If it doesn't, I think that should be
> > considered a bug in dpkg, since you may be invoking a command that links
> > against a library whose soname has changed since the last time the pre-dep
> > package was configured.  If it /does/ provide this guarantee, I think it
> > should be documented in Policy.

> Should I file a policy bug to clarify this?

I think that would be a good idea, yes - thanks!

> [...]
> >> +	      The <prgn>postrm</prgn> script is called after the package's
> >> +	      files have been removed or replaced.  The package
> >> +	      whose <prgn>postrm</prgn> is being called may have
> >> +	      previously been deconfigured and only be unpacked, at which
> >> +	      point subsequent package changes do not consider its
> >> +	      dependencies.
> [...]
> > True as written, but less helpful than it should be.  There are a number of
> > cases where postrm scripts still need to *try* to invoke non-essential
> > functionality, and fail gracefully if it's unavailable

> Yes, that is worth mentioning.  Actually it has very little to do with
> dependencies.

> For example, many packages only use “Suggests: doc-base” but have
> snippets like the following in prerm:

> 	# Automatically added by dh_installdocs
> 	if [ "$1" = remove ] || [ "$1" = upgrade ] && \
> 	   which install-docs >/dev/null 2>&1; then
> 		install-docs -r whatever
> 	fi

> Maybe a footnote would be appropriate?  Something along these lines:

I think it needs to be stronger than a footnote; what we're describing here
is one of the primary uses of postrm scripts.

> 	This is not intended to excuse packages from the obligation
> 	to clean up after themselves when they have placed some
> 	state in a non-essential package's care.  The usual strategy
> 	for that is as follows:

This language seems pretty good.

> 	If you have a package that manages a configuration file
> 	with ucf, you must call "ucf --purge" from postrm if ucf is
> 	present on the system at that point.  If ucf is not present,
> 	then the configuration file is in its care and will be
> 	removed when ucf is purged.

I think Russ's example is better than this textual description of the
process.

> >> @@ -4588,12 +4651,17 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
> >>  
> >>  	      <p>
> >>  		The <tt>Depends</tt> field should also be used if the
> >> -		<prgn>postinst</prgn>, <prgn>prerm</prgn> or
> >> -		<prgn>postrm</prgn> scripts require the package to be
> >> -		present in order to run.
> >> +		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
> >> +		require the depended-on package to be unpacked or
> >> +		configured in order to run.
> [...]
> > I disagree with this change.
> [...]
> > The normal use case is "whichever of the two packages is removed first must
> > clean up".  While I can't think of a case where the cleanup interface called
> > from the postrm isn't already a dependency for other reasons (e.g., for use
> > in the postinst), I'd like this to be explicit all the same.

> Given the explanation above, do you still think Depends should be used
> this way?

Yes, absolutely!  If there's some operation that /should/ be done in the
postrm if at all possible, and we want to give ourselves the best possible
odds that we'll be able to, a Depends is the way to achieve that.  The
package manager won't guarantee the dependency is installed at postrm time,
but this is as good as we can get.

Consider this sequence:

   foo install registers a file with ucf
   foo is removed
   ucf is removed
   foo is purged; because ucf is no longer installed, the config file
      information is kept in place
   foo is reinstalled, pulling in ucf - and the old config file is restored,
      contrary to the definition of 'purge'

Is ucf misbehaving by not removing its state on package removal?  I can't
say so; I think it's behaving the way Policy expects it to.  Likewise, foo
isn't wrong for failing to remove its config data from ucf on package
removal (i.e., in prerm).  So both packages are perfectly policy-compliant,
but in this corner case the outcome is incorrect.

It'll always be possible to end up with such a sequence as a result of
manual action on the part of the user, but I think we should do our best to
avoid landing a user in this situation automatically.  Having foo Depends:
ucf, and ensuring the package manager removes packages in reverse dependency
order where possible (which I believe is currently the case), is the best
way to accomplish this.  It won't guard against the "remove, then purge
later" situation, but it will help for cases where the deregistration of
data is done in postrm remove.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sun, 15 Aug 2010 21:18:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 15 Aug 2010 21:18:12 GMT) Full text and rfc822 format available.

Message #310 received at 504880@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Russ Allbery <rra@debian.org>, 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 15 Aug 2010 14:17:51 -0700
On Sun, Aug 15, 2010 at 03:24:59PM -0500, Jonathan Nieder wrote:
> > As Steve pointed out, this is generally going to be a no-op, since if
> > you're cleaning something up in postrm, you probably already depended on
> > it because you're using it in postinst.

> Example where it is not a no-op: doc-base

> In that example, neither Recommends nor Depends is appropriate, true.

This is an obsolete example, doc-base now uses a trigger as it ought to and
the install-docs command is now a no-op (+ a warning message) when called
from a maintainer script. :-)

Do you have an example of using Suggests: in this way that *shouldn't* be
converted to a trigger instead?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sun, 15 Aug 2010 21:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 15 Aug 2010 21:24:03 GMT) Full text and rfc822 format available.

Message #315 received at 504880@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>, 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 15 Aug 2010 16:20:22 -0500
Steve Langasek wrote:

> This is an obsolete example, doc-base now uses a trigger as it ought to and
> the install-docs command is now a no-op (+ a warning message) when called
> from a maintainer script. :-)
> 
> Do you have an example of using Suggests: in this way that *shouldn't* be
> converted to a trigger instead?

No, I think everything following that pattern could (and should) use
triggers.

Thanks for the explanation.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Sun, 15 Aug 2010 21:51:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 15 Aug 2010 21:51:06 GMT) Full text and rfc822 format available.

Message #320 received at 504880@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 15 Aug 2010 16:47:01 -0500
Based on Steve’s explanation:

Russ Allbery wrote:

> 	      <p>
> 		The <tt>Depends</tt> field should also be used if the
> 		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
> 		require the depended-on package to be unpacked or
> 		configured in order to run, or if the dependend-on package
> 		is desirable for cleanup done by <prgn>postrm</prgn>.

Desirable is too weak.  I think this case is complicated enough to
deserve its own paragraph.

 The <tt>Depends</tt> field should also be used if the
 <prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
 require the depended-on package to be unpacked or
[as before ...]
 previous upgrade of the dependency failed.

 The <tt>Depends</tt> field should also be used if an
 operation that ought to be done in <prgn>postrm</prgn>
 requires the depended-on package.

> 		                    In the case of <prgn>postrm</prgn>,
> 		there are no guarantees, but the depended-on package is
> 		more likely to be available

                                    This does not
 guarantee that the depended-on package will be available
 when <prgn>postrm</prgn> is run, but it makes it more
 likely.

> 		The <prgn>postrm</prgn> script must cleanly skip actions
> 		that require a dependency if that dependency isn't
> 		available.

          The <prgn>postrm</prgn> script must gracefully
 skip actions that require a dependency if that dependency
 isn't available.  The depended-on package should ensure
 that the corresponding state is cleaned up when <em>it</em>
 is purged.

(with a pointer to the example in #mscriptsinstact)

Sensible?




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Mon, 16 Aug 2010 00:54:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 16 Aug 2010 00:54:03 GMT) Full text and rfc822 format available.

Message #325 received at 504880@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 15 Aug 2010 17:50:44 -0700
On Sun, Aug 15, 2010 at 12:25:19PM -0700, Russ Allbery wrote:
> > Does dpkg provide any guarantee that the dependencies of the
> > pre-dependency are also present at this point?  If it doesn't, I think
> > that should be considered a bug in dpkg, since you may be invoking a
> > command that links against a library whose soname has changed since the
> > last time the pre-dep package was configured.  If it /does/ provide this
> > guarantee, I think it should be documented in Policy.

> I believe they can be in the same state as the pre-dependency itself for
> exactly the same reasons, no?  Upgrades don't require deconfiguring
> packages that depend on the package being upgraded, so if you abort in the
> middle of upgrading a package the pre-dependency depends on, the
> pre-dependency is still present and configured on the system, so dpkg will
> treat the pre-dependency as satisfied.

The question is, if you upgrade a package which is a pre-dependency of
another package, are any *new* dependencies of that package guaranteed to be
unpacked before the package itself is?

This seems like a sensible thing for the package manager to enforce, but I
don't know if anything does so in practice.

> >> +	      unpacked in some error situations.<footnote>
> >> +		For example, suppose packages foo and bar are installed
> >> +		with foo depending on bar.  If an upgrade of bar were
> >> +		started and then aborted, and then an attempt to remove
> >> +		foo failed because its <prgn>prerm</prgn> script failed,
> >> +		foo's <tt>postinst abort-remove</tt> would be called with
> >> +		bar only "Half-Installed".
> >> +	      </footnote>
> >>  	    </item>
> >> -	  </list>
> >> +	  </taglist>
> >> +	</p>

> > This footnote is interesting to me because although it accurately
> > documents dpkg's behavior, I'm not sure what implications it has for how
> > packages should guard against this case.  I think I've always ignored
> > this possibility in my maintainer scripts, and will continue to do so on
> > the grounds that any attempt to handle this gracefully is likely to
> > introduce much greater complexity (and therefore bugs) with very little
> > upside (when all is said and done, a package you were trying to remove
> > is still installed, so do we care if it configures successfully?)

> > If we can make a straightforward recommendation to maintainers for how
> > to handle this case, I think we should include that in the footnote.
> > Otherwise, if it shouldn't affect how we write maintainer scripts,
> > perhaps it's better not to have this footnote at all since it would only
> > lead to maintainers trying to be too clever and shooting themselves in
> > the foot?

> I think we should put it in the main text.  I've now added, after the
> footnote and in the main text:

> 	      The <prgn>postinst</prgn> should still attempt any actions
> 	      for which its dependencies are required, since they will
> 	      normally be available, but consider the correct error
> 	      handling approach if those actions fail.  Aborting
> 	      the <prgn>postinst</prgn> action if commands or facilities
> 	      from the package dependencies are not available is often the
> 	      best approach.

> which I think is roughly what you're doing and what most people are doing
> and which I think is the generally best approach.

Sounds good to me, thanks.

> >>  	      <p>
> >>  		The <tt>Depends</tt> field should also be used if the
> >> -		<prgn>postinst</prgn>, <prgn>prerm</prgn> or
> >> -		<prgn>postrm</prgn> scripts require the package to be
> >> -		present in order to run.  Note, however, that the
> >> -		<prgn>postrm</prgn> cannot rely on any non-essential
> >> -		packages to be present during the <tt>purge</tt>
> >> -		phase.
> >> +		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
> >> +		require the depended-on package to be unpacked or
> >> +		configured in order to run.  In the case of <tt>postinst
> >> +		configure</tt>, the depended-on packages will be unpacked
> >> +		and configured first.  (If both packages are involved in a
> >> +		dependency loop, this might not work as expected; see the
> >> +		explanation a few paragraphs back.)  In the case
> >> +		of <prgn>prerm</prgn> or other <prgn>postinst</prgn>
> >> +		actions, the package dependencies will be at least
> >> +		unpacked or "Half-Installed".
> >> +	      </p>
> >>  	    </item>

> > I disagree with this change.  If you are making use of non-essential
> > packages in your postrm, you *should* use the Depends: field; you just
> > *also* have to have a clean fallback plan if the dependency is not
> > satisfied when the postrm is called.

> > The normal use case is "whichever of the two packages is removed first
> > must clean up".  While I can't think of a case where the cleanup
> > interface called from the postrm isn't already a dependency for other
> > reasons (e.g., for use in the postinst), I'd like this to be explicit
> > all the same.

> How about this?

> 	      <p>
> 		The <tt>Depends</tt> field should also be used if the
> 		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
> 		require the depended-on package to be unpacked or
> 		configured in order to run, or if the dependend-on package
> 		is desirable for cleanup done by <prgn>postrm</prgn>.  In
> 		the case of <tt>postinst configure</tt>, the depended-on
> 		packages will be unpacked and configured first.  (If both
> 		packages are involved in a dependency loop, this might not
> 		work as expected; see the explanation a few paragraphs
> 		back.)  In the case of <prgn>prerm</prgn> or
> 		other <prgn>postinst</prgn> actions, the package
> 		dependencies will normally be at least unpacked, but they
> 		may be only "Half-Installed" if a previous upgrade of the
> 		dependency failed.  In the case of <prgn>postrm</prgn>,
> 		there are no guarantees, but the depended-on package is
> 		more likely to be available if the package declares a
> 		dependency (particularly for <tt>postrm remove</tt>).
> 		The <prgn>postrm</prgn> script must cleanly skip actions
> 		that require a dependency if that dependency isn't
> 		available.
> 	      </p>

s/desirable/wanted/?

and s/dependend/depended/ :)

Seems ok to me.  Better than Jonathan's proposed wording, which doesn't read
well because there's too much repetition.

I might also add at the end:

  In such situations, the depended-on package should perform an equivalent
  clean-up operation if it's the first package to be removed or purged.

But that may not be unambiguous enough to add any value here and I can't be
bothered to further tune the language right now; I don't think that's a
blocker and this bug has run quite long enough already.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Wed, 18 Aug 2010 18:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 18 Aug 2010 18:54:03 GMT) Full text and rfc822 format available.

Message #330 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 504880@bugs.debian.org
Cc: Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Wed, 18 Aug 2010 11:50:35 -0700
Steve Langasek <vorlon@debian.org> writes:
> On Sun, Aug 15, 2010 at 12:25:19PM -0700, Russ Allbery wrote:

>> I believe they can be in the same state as the pre-dependency itself
>> for exactly the same reasons, no?  Upgrades don't require deconfiguring
>> packages that depend on the package being upgraded, so if you abort in
>> the middle of upgrading a package the pre-dependency depends on, the
>> pre-dependency is still present and configured on the system, so dpkg
>> will treat the pre-dependency as satisfied.

> The question is, if you upgrade a package which is a pre-dependency of
> another package, are any *new* dependencies of that package guaranteed
> to be unpacked before the package itself is?

> This seems like a sensible thing for the package manager to enforce, but
> I don't know if anything does so in practice.

I think I've lost track of all the packages here and am not entirely sure
what you're describing, but regardless we should probably move this part
of things into #593177, which is specifically about this.

> s/desirable/wanted/?

> and s/dependend/depended/ :)

> Seems ok to me.  Better than Jonathan's proposed wording, which doesn't
> read well because there's too much repetition.

> I might also add at the end:

>   In such situations, the depended-on package should perform an equivalent
>   clean-up operation if it's the first package to be removed or purged.

> But that may not be unambiguous enough to add any value here and I can't
> be bothered to further tune the language right now; I don't think that's
> a blocker and this bug has run quite long enough already.

I'm going to bail on that because of the length of the bug; I'd really
like to get this merged, since it's blocking resolving a few other bugs
that touch the same areas of wording.

I think it does read slightly better as two paragraphs.  Here's what I
have now:

	      <p>
		The <tt>Depends</tt> field should also be used if the
		<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
		require the depended-on package to be unpacked or
		configured in order to run.  In the case of <tt>postinst
		configure</tt>, the depended-on packages will be unpacked
		and configured first.  (If both packages are involved in a
		dependency loop, this might not work as expected; see the
		explanation a few paragraphs back.)  In the case
		of <prgn>prerm</prgn> or other <prgn>postinst</prgn>
		actions, the package dependencies will normally be at
		least unpacked, but they may be only "Half-Installed" if a
		previous upgrade of the dependency failed.
	      </p>

	      <p>
		Finally, the <tt>Depends</tt> field should be used if the
		depended-on package is needed by the <prgn>postrm</prgn>
		script to fully clean up after the package removal.  There
		is no guarantee that package dependencies will be
		available when <prgn>postrm</prgn> is run, but the
		depended-on package is more likely to be available if the
		package declares a dependency (particularly in the case
		of <tt>postrm remove</tt>).  The <prgn>postrm</prgn>
		script must gracefully skip actions that require a
		dependency if that dependency isn't available.
	      </p>

Does that look okay?

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Added indication that bug 504880 blocks 582109 Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Wed, 18 Aug 2010 19:48:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Wed, 18 Aug 2010 22:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 18 Aug 2010 22:33:03 GMT) Full text and rfc822 format available.

Message #337 received at 504880@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Wed, 18 Aug 2010 17:28:15 -0500
Russ Allbery wrote:
> Steve Langasek <vorlon@debian.org> writes:

>> I might also add at the end:
>
>>   In such situations, the depended-on package should perform an equivalent
>>   clean-up operation if it's the first package to be removed or purged.
>
>> But that may not be unambiguous enough to add any value here and I can't
>> be bothered to further tune the language right now; I don't think that's
>> a blocker and this bug has run quite long enough already.
>
> I'm going to bail on that because of the length of the bug

Reasonable.  When making a suggestion for a new normative requirement
like that, I probably should have just filed a new (low-severity)
policy bug.

[...]
> Does that look okay?

Yes, that is much clearer.

Thanks again, and sorry to nitpick so.




Added indication that bug 504880 blocks 425523 Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Wed, 18 Aug 2010 22:45:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Fri, 20 Aug 2010 23:09:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 20 Aug 2010 23:09:07 GMT) Full text and rfc822 format available.

Message #344 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 504880@bugs.debian.org, Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Fri, 20 Aug 2010 16:06:51 -0700
Jonathan Nieder <jrnieder@gmail.com> writes:
> Russ Allbery wrote:
>> Steve Langasek <vorlon@debian.org> writes:

>>> I might also add at the end:

>>>   In such situations, the depended-on package should perform an
>>>   equivalent clean-up operation if it's the first package to be
>>>   removed or purged.

>>> But that may not be unambiguous enough to add any value here and I
>>> can't be bothered to further tune the language right now; I don't
>>> think that's a blocker and this bug has run quite long enough already.

>> I'm going to bail on that because of the length of the bug

> Reasonable.  When making a suggestion for a new normative requirement
> like that, I probably should have just filed a new (low-severity) policy
> bug.

Please do feel free if you think it looks worthwhile to document.

> [...]
>> Does that look okay?

> Yes, that is much clearer.

> Thanks again, and sorry to nitpick so.

It's much appreciated, actually.  I want to improve the clarity of the
language, so other people checking it for clarity is always helpful.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Owner recorded as Russ Allbery <rra@debian.org>. Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Sat, 21 Aug 2010 00:39:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Russ Allbery <rra@debian.org>:
Bug#504880; Package debian-policy. (Sat, 05 Mar 2011 00:00:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Russ Allbery <rra@debian.org>. (Sat, 05 Mar 2011 00:00:06 GMT) Full text and rfc822 format available.

Message #351 received at 504880@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: 504880@bugs.debian.org
Cc: Colin Watson <cjwatson@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Disambiguate "installed" for packages
Date: Fri, 4 Mar 2011 17:58:05 -0600
[Message part 1 (text/plain, inline)]
Russ Allbery wrote:

> Does that look okay?

Yes, the version in branch 504880-rra looks good to me (with one
tweak:

 --- a/policy.sgml
 +++ b/policy.sgml
 @@ -4027,5 +4027,5 @@ fi
  		in <prgn>postrm</prgn> purges the <prgn>debconf</prgn>
  		configuration for the package
  		if <package>debconf</package> is installed.
 -	      </foonote>
 +	      </footnote>
  	    </item>

)  I suspect others like it, too, but who knows?  Patch attached.
Seconds or objections welcome.
[bug504880 (text/plain, attachment)]

Forcibly Merged 403649 504880. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Sat, 05 Mar 2011 03:33:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Russ Allbery <rra@debian.org>:
Bug#504880; Package debian-policy. (Sat, 05 Mar 2011 08:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Russ Allbery <rra@debian.org>. (Sat, 05 Mar 2011 08:36:03 GMT) Full text and rfc822 format available.

Message #358 received at 504880@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 504880@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Disambiguate "installed" for packages
Date: Sat, 5 Mar 2011 09:32:52 +0100
[Message part 1 (text/plain, inline)]
Hi,

On Fri, 04 Mar 2011, Jonathan Nieder wrote:
> )  I suspect others like it, too, but who knows?  Patch attached.
> Seconds or objections welcome.

Seconded. It's long and I might have missed some inaccuracies but I think
it's an improvement in clarity.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)
[signature.asc (application/pgp-signature, inline)]

Added tag(s) pending; removed tag(s) patch. Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Mon, 04 Apr 2011 04:12:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#504880; Package debian-policy. (Mon, 04 Apr 2011 04:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 04 Apr 2011 04:18:03 GMT) Full text and rfc822 format available.

Message #365 received at 504880@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 504880@bugs.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#504880: Disambiguate "installed" for packages
Date: Sun, 03 Apr 2011 21:08:39 -0700
Raphael Hertzog <hertzog@debian.org> writes:
> On Fri, 04 Mar 2011, Jonathan Nieder wrote:

>> )  I suspect others like it, too, but who knows?  Patch attached.
>> Seconds or objections welcome.

> Seconded. It's long and I might have missed some inaccuracies but I think
> it's an improvement in clarity.

Thanks!

With this and with Steve's earlier approval, I'm going to call this good
enough and merge this monster.  We can definitely fix any problems that I
introduced later on after more people have had a chance to study it and
apply it to their packages.

Thank you, everyone, for all your reviews of this giant patch.  I think it
will be a great first step towards making maintainer script state less
confusing.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Reply sent to Russ Allbery <rra@debian.org>:
You have taken responsibility. (Thu, 07 Apr 2011 06:11:21 GMT) Full text and rfc822 format available.

Notification sent to Colin Watson <cjwatson@debian.org>:
Bug acknowledged by developer. (Thu, 07 Apr 2011 06:11:38 GMT) Full text and rfc822 format available.

Message #370 received at 504880-close@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 504880-close@bugs.debian.org
Subject: Bug#504880: fixed in debian-policy 3.9.2.0
Date: Thu, 07 Apr 2011 06:02:15 +0000
Source: debian-policy
Source-Version: 3.9.2.0

We believe that the bug you reported is fixed in the latest version of
debian-policy, which is due to be installed in the Debian FTP archive:

debian-policy_3.9.2.0.dsc
  to main/d/debian-policy/debian-policy_3.9.2.0.dsc
debian-policy_3.9.2.0.tar.gz
  to main/d/debian-policy/debian-policy_3.9.2.0.tar.gz
debian-policy_3.9.2.0_all.deb
  to main/d/debian-policy/debian-policy_3.9.2.0_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 504880@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Russ Allbery <rra@debian.org> (supplier of updated debian-policy package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Wed, 06 Apr 2011 22:48:55 -0700
Source: debian-policy
Binary: debian-policy
Architecture: source all
Version: 3.9.2.0
Distribution: unstable
Urgency: low
Maintainer: Debian Policy List <debian-policy@lists.debian.org>
Changed-By: Russ Allbery <rra@debian.org>
Description: 
 debian-policy - Debian Policy Manual and related documents
Closes: 459868 488214 501930 504880 536790 581011 588014 590696 591857 593909 594274 594542 594656 594658 597074 599944 606869 609160 619186
Changes: 
 debian-policy (3.9.2.0) unstable; urgency=low
 .
   * Policy: Require human Maintainer or Uploader, clarify Maintainer
     Wording: Russ Allbery <rra@debian.org>
     Seconded: Charles Plessy <plessy@debian.org>
     Seconded: Raphaël Hertzog <hertzog@debian.org>
     Closes: #459868, #581011
   * Policy: Add an FHS exception on GNU/Hurd for /hurd and /servers
     Wording: Russ Allbery <rra@debian.org>
     Seconded: Andrew McMillan <andrew@morphoss.com>
     Seconded: Guillem Jover <guillem@debian.org>
     Closes: #594658
   * Policy: Document DM-Upload-Allowed
     Wording: Charles Plessy <plessy@debian.org>
     Seconded: Andrew McMillan <andrew@morphoss.com>
     Seconded: Russ Allbery <rra@debian.org>
     Closes: #588014
   * Policy: Update multiarch FHS exception for i386 naming
     Wording: Steve Langasek <vorlon@debian.org>
     Seconded: Aurelien Jarno <aurelien@aurel32.net>
     Seconded: Raphael Hertzog <hertzog@debian.org>
     Closes: #619186
   * Policy: Significant additions to maintainer script documentation
     Wording: Russ Allbery <rra@debian.org>
     Seconded: Steve Langasek <vorlon@debian.org>
     Seconded: Raphaël Hertzog <hertzog@debian.org>
     Closes: #504880
   * Policy: Clarify format of Debian control fields
     Wording: Charles Plessy <plessy@debian.org>
     Seconded: Russ Allbery <rra@debian.org>
     Seconded: Julien Cristau <jcristau@debian.org>
     Closes: #501930, #593909
   * Virtual: Added mailx as a new virtual package
     Wording: Russ Allbery <rra@debian.org>
     Seconded: Raphaël Hertzog <hertzog@debian.org>
     Seconded: Giacomo A. Catenazzi <cate@debian.org>
     Closes: #488214
   * Be more verbose in defining the build architecture and the host
     architecture and consistently refer to architecture rather than
     machine.  (Closes: #591857)
   * Correct the name of the Filesystem Hierarchy Standard in the package
     description.  Patch from Christoph Anton Mitterer.  (Closes: #590696)
   * Use the word "implemented" to describe required targets in
     debian/rules, which is clearer about allowing wildcard rules.  List
     the required rules in their own paragraph rather than with the
     paragraph discussing non-interactivity, and explicitly mark all rules
     as either required or optional.  (Closes: #536790)
   * Update the ldconfig footnote listing the /etc/ld.so.conf directories
     to remove the libc5 compatibility directories and mention the
     multiarch triplet directories.  Based on a patch by Charles Plessy.
     (Closes: #597074)
   * Add introductory paragraphs for each archive area explaining briefly
     the purpose of that archive area.  Based on a proposal by CJ
     Fearnley.  (Closes: #594542)
   * Change all non-historical references to Debian GNU/Linux to simply
     Debian since Debian now includes FreeBSD-based architectures.  Patch
     from Guillem Jover.  (Closes: #594656)
   * Remove references to the obsolete debmake package.
   * Update the list of Policy maintainers.
   * Wrap Uploaders in debian/control.
   * Move Build-Depends-Indep to Build-Depends (there's no reason to use
     -Indep in a package that builds only architecture-independent binary
     packages), wrap it, and remove version restrictions that are older
     than the version in oldstable.
   * Add emacs23 to the build dependencies and remove the files generated
     from org source from the revision control repository.  Build and clean
     files from org source unconditionally.  Add Process.{txt,html} to the
     list of files generated from org source.  (Closes: #594274)
   * Fix URLs under www.freedesktop.org to avoid permanent redirects.
     Thanks, David Prévot.  (Closes: #606869)
   * Add a cross-reference to the Pre-Depends requirement in 3.5 to section
     7.2 where Pre-Depends is defined.  Thanks, Mattias Ellert and Jonathan
     Nieder.  (Closes: #599944)
   * Include the new (optional) copyright format that was drafted as DEP-5.
     This is not yet a final version; that's expected to come in the
     3.9.3.0 release.  Thanks to all the DEP-5 contributors and to Lars
     Wirzenius and Charles Plessy for the integration into the Policy
     package.  (Closes: #609160)
Checksums-Sha1: 
 3fbe1185dd3abd9f553cefbc2e8b353864bdd99b 1471 debian-policy_3.9.2.0.dsc
 f8b59ed7adcaec2dd78b77010eba9f9934e13012 693834 debian-policy_3.9.2.0.tar.gz
 3854a70a825272ff6a1e1473eb90369f5c1c6c68 1907938 debian-policy_3.9.2.0_all.deb
Checksums-Sha256: 
 231893c0f9dd4d8bd20aa5d53e871423c15ce0eb48ebc53652316a0e7eca8f89 1471 debian-policy_3.9.2.0.dsc
 8be1c13c6b05b167b356f505cab74f3e6a84be096215e64ad741d672b6f943a6 693834 debian-policy_3.9.2.0.tar.gz
 1a587553e9fc5ad93f3ddf8d752131efc737dff7810a6c170fe67cbb8a642eb5 1907938 debian-policy_3.9.2.0_all.deb
Files: 
 cad30289440ae005513484e7af83039f 1471 doc optional debian-policy_3.9.2.0.dsc
 b90105f64bcaedd3b1c182689ac9c6c8 693834 doc optional debian-policy_3.9.2.0.tar.gz
 73bef9fc65be0091233daa701e494104 1907938 doc optional debian-policy_3.9.2.0_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJNnVKxAAoJEH2AMVxXNt51S1kH/19xBm48ZzXnn2tSEHaCWKIz
sh86ppJArmwvxUu0BzwlSg2jr01M3pyynwVzgevGAQ9QlK2bD1MODlq5zQ23JLk8
ZHthYq/f15BkWuwMPVfnWeUtLVe4Xo6LL/LJGMjYiWTGxyv8OtctDVYz0olksmjr
gNp4rTUIzRfL8ucN3ypq0Xct7K2QilXQFdtEpHSRdsSPLC42cQgH/0wqo1PzMT7w
micFsqgGT5ZDUq+y4eNE6AzAZynVJgUAgnG0BMANucFJ8pVnVPmUB8rAEaURPGib
rjwuIHftPliJyI0hoBzWV1AU9t/I7IPekCJx+eqhVnUMF+sQexwHssEWmAZbtwY=
=o5f6
-----END PGP SIGNATURE-----





Reply sent to Russ Allbery <rra@debian.org>:
You have taken responsibility. (Thu, 07 Apr 2011 06:12:01 GMT) Full text and rfc822 format available.

Notification sent to Frank Küster <frank@debian.org>:
Bug acknowledged by developer. (Thu, 07 Apr 2011 06:12:36 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 15 May 2011 07:35:52 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 02:07:13 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.