Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Raphael Hertzog  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 (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Raphael Hertzog]

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
Description: Digital signature

Bug#504880: Disambiguate "installed" for packages

[Jonathan Nieder]

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 postrm purges the debconf
configuration for the package
if debconf is installed.
 -
 +


)  I suspect others like it, too, but who knows?  Patch attached.
Seconds or objections welcome.
diff --git a/policy.sgml b/policy.sgml
index 6e04c81..d0e3ae9 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1133,10 +1133,10 @@

 

- Sometimes, a package requires another package to be installed
- and configured before it can be installed. In this
- case, you must specify a Pre-Depends entry for
- the package.
+ Sometimes, unpacking one package requires that another package
+ be first unpacked and configured.  In this case, the
+ depending package must specify this dependency in
+ the Pre-Depends control field.

 

@@ -3776,7 +3776,7 @@ Checksums-Sha256:
 

  Broadly speaking the preinst is called before
- (a particular version of) a package is installed, and the
+ (a particular version of) a package is unpacked, and the
  postinst afterwards; the prerm
  before (a version of) a package is removed and the
  postrm afterwards.
@@ -3860,111 +3860,200 @@ Checksums-Sha256:

 

- 
-   
- new-preinst install
-   
-   
- new-preinst install old-version
-   
-   
-   new-preinst upgrade old-version
-   
-   
-   old-preinst abort-upgrade
-   new-version
-   
- 
+ 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 new- are the scripts from the new version of a
+ package being installed, upgraded to, or downgraded to.  Script
+ names preceded by old- are the scripts from the old
+ version of a package that is being upgraded from or downgraded
+ from.
+   
 

- 
-   
-   postinst configure
-   most-recently-configured-version
-   
-   
-   old-postinst abort-upgrade
-   new-version
-   
-   
-   conflictor's-postinst abort-remove
-   in-favour package
-   new-version
-   
+ The preinst script may be called in the following
+ ways:
+ 
+   new-preinst install
+   new-preinst install
+ old-version
+   new-preinst upgrade
+ old-version

-   postinst abort-remove
+ The package will not yet be unpacked, so
+ the preinst script cannot rely on any files
+ included in its package.  Only essential packages and
+ pre-dependencies (Pre-Depends) may be assumed to be
+ available.  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 since then.

+
+   old-preinst abort-upgrade
+ new-version

-   deconfigured's-postinst
-   abort-deconfigure in-favour
-   failed-install-package version
-   [removing conflicting-package
-   version]
+ Called during error handling of an upgrade that failed after
+ unpacking the new package because the postrm
+ upgrade 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.
+   This can happen if the new version of the package no
+   longer pre-depends on a package that had been partially
+   upgraded.
+ 

- 
+ 
+   
 

- 
-   
-   prerm remove
-   
-   
-   old-prerm upgrade
-   new-version
-   
-   
-   new-prerm failed-upgrade
-   old-version
-   
+ The postinst scrip

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Jonathan Nieder  writes:
> Russ Allbery wrote:
>> Steve Langasek  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 (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Jonathan Nieder]

Russ Allbery wrote:
> Steve Langasek  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.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Steve Langasek  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:

  
The Depends field should also be used if the
postinst or prerm scripts
require the depended-on package to be unpacked or
configured in order to run.  In the case of postinst
configure, 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 prerm or other postinst
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.
  

  
Finally, the Depends field should be used if the
depended-on package is needed by the postrm
script to fully clean up after the package removal.  There
is no guarantee that package dependencies will be
available when postrm is run, but the
depended-on package is more likely to be available if the
package declares a dependency (particularly in the case
of postrm remove).  The postrm
script must gracefully skip actions that require a
dependency if that dependency isn't available.
  

Does that look okay?

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Steve Langasek]

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.
> >> +  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 prerm script failed,
> >> +  foo's postinst abort-remove would be called with
> >> +  bar only "Half-Installed".
> >> +
> >>
> >> -
> >> +
> >> +  

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

> >>  
> >>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.
> >> +  postinst or prerm scripts
> >> +  require the depended-on package to be unpacked or
> >> +  configured in order to run.  In the case of postinst
> >> +  configure, 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 prerm or other postinst
> >> +  actions, the package dependencies will be at least
> >> +  unpacked or "Half-Installed".
> >> +
> >>

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

> 
>  

Bug#504880: Disambiguate "installed" for packages

[Jonathan Nieder]

Based on Steve’s explanation:

Russ Allbery wrote:

> 
>   The Depends field should also be used if the
>   postinst or prerm 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 postrm.

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

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

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

>   In the case of postrm,
>   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 postrm is run, but it makes it more
 likely.

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

  The postrm 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 it
 is purged.

(with a pointer to the example in #mscriptsinstact)

Sensible?



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Jonathan Nieder]

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.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Steve Langasek]

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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Steve Langasek]

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 postrm script is called after the package's
> >> +files have been removed or replaced.  The package
> >> +whose postrm 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]
> >>  
> >>  
> >>The Depends field should also be used if the
> >> -  postinst, prerm or
> >> -  postrm scripts require the package to be
> >> -  present in order to run.
> >> +  postinst or prerm 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 ca

Bug#504880: Disambiguate "installed" for packages

[Bill Allombert]

On Sun, Aug 15, 2010 at 02:57:18PM -0500, Jonathan Nieder wrote:
> Russ Allbery wrote:
> 
> > How about this?
> > 
> >   
> > The Depends field should also be used if the
> > postinst or prerm 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 postrm.
> 
> 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. 

Imagine a large red swirl here. 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Jonathan Nieder]

Russ Allbery wrote:
> Jonathan Nieder  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.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Jonathan Nieder  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 (r...@debian.org)   



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Jonathan Nieder]

Russ Allbery wrote:
> Jonathan Nieder  writes:
>> Russ Allbery wrote:

>>> The Depends field should also be used if
[...]
>>>   the dependend-on package
>>> is desirable for cleanup done by postrm.
>
>> 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.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Jonathan Nieder  writes:
> Russ Allbery wrote:

>> How about this?
>> 
>>
>>  The Depends field should also be used if the
>>  postinst or prerm 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 postrm.

> 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 (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Jonathan Nieder]

Russ Allbery wrote:

> How about this?
> 
> 
>   The Depends field should also be used if the
>   postinst or prerm 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 postrm.

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

Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Raphael Hertzog]

On Sun, 15 Aug 2010, Russ Allbery wrote:
> Raphael Hertzog  writes:
> > On Mon, 26 Jul 2010, Russ Allbery wrote:
> 
> >>
> >>  The DEBIAN directory will not appear in the
> >>  file system archive of the package, and so won't be installed
> >> -by dpkg when the package is installed.
> >> +by dpkg when the package is unpacked.
> >>
> 
> > 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)



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

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

 

- Sometimes, a package requires another package to be installed
- and configured before it can be installed. In this
- case, you must specify a Pre-Depends entry for
- the package.
+ Sometimes, unpacking one package requires that another package
+ be first unpacked and configured.  In this case, the
+ depending package must specify this dependency in
+ the Pre-Depends control field.

 

@@ -3727,7 +3727,7 @@ Checksums-Sha256:
 

  Broadly speaking the preinst is called before
- (a particular version of) a package is installed, and the
+ (a particular version of) a package is unpacked, and the
  postinst afterwards; the prerm
  before (a version of) a package is removed and the
  postrm afterwards.
@@ -3811,111 +3811,200 @@ Checksums-Sha256:

 

- 
-   
- new-preinst install
-   
-   
- new-preinst install old-version
-   
-   
-   new-preinst upgrade old-version
-   
-   
-   old-preinst abort-upgrade
-   new-version
-   
- 
+ 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 new- are the scripts from the new version of a
+ package being installed, upgraded to, or downgraded to.  Script
+ names preceded by old- are the scripts from the old
+ version of a package that is being upgraded from or downgraded
+ from.
+   
 

- 
-   
-   postinst configure
-   most-recently-configured-version
-   
-   
-   old-postinst abort-upgrade
-   new-version
-   
-   
-   conflictor's-postinst abort-remove
-   in-favour package
-   new-version
-   
+ The preinst script may be called in the following
+ ways:
+ 
+   new-preinst install
+   new-preinst install
+ old-version
+   new-preinst upgrade
+ old-version

-   postinst abort-remove
+ The package will not yet be unpacked, so
+ the preinst script cannot rely on any files
+ included in its package.  Only essential packages and
+ pre-dependencies (Pre-Depends) may be assumed to be
+ available.  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 since then.

+
+   old-preinst abort-upgrade
+ new-version

-   deconfigured's-postinst
-   abort-deconfigure in-favour
-   failed-install-package version
-   [removing conflicting-package
-   version]
+ Called during error handling of an upgrade that failed after
+ unpacking the new package because the postrm
+ upgrade 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.
+   This can happen if the new version of the package no
+   longer pre-depends on a package that had been partially
+   upgraded.
+ 

- 
+ 
+   
 

- 
-   
-   prerm remove
-   
-   
-   old-prerm upgrade
-   new-version
-   
-   
-   new-prerm failed-upgrade
-   old-version
-   
+ The postinst script may be called in the following
+ ways:
+ 
+   postinst configure
+ most-recently-configured-version

-   conflictor's-prerm remove
-   in-favour package
-   new-version
+ The files contained in the package will be unpacked.  All
+ package dependencies will at least be unpacked.  If there
+ are 

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Steve Langasek  writes:
> On Wed, Jul 21, 2010 at 01:52:50PM -0700, Russ Allbery wrote:

>> +  Sometimes, a package requires another package to be unpacked
>> +  and configured before it can be unpacked.  In this
>> +  case, the dependent package must specify this dependency in
>> +  the Pre-Depends 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 preinst script cannot rely on any files
>> +  included in its package.  Only essential packages and
>> +  pre-dependencies (Pre-Depends) 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.
>>  

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

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

Added a reference.

>> +  unpacked in some error situations.
>> +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 prerm script failed,
>> +foo's postinst abort-remove would be called with
>> +bar only "Half-Installed".
>> +  
>>  
>> -  
>> +  
>> +

> 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 postinst 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 postinst 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 postrm script is called after the package's
>> +  files have been rem

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Raphael Hertzog  writes:
> On Mon, 26 Jul 2010, Russ Allbery wrote:

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

> 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 (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Jonathan Nieder]

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 Pre-Depends 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.
>>  
>
> 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?

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

Maybe something as simple as “(See also )”.

>> +  unpacked in some error situations.
>> +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 prerm script failed,
>> +foo's postinst abort-remove would be called with
>> +bar only "Half-Installed".
>> +  
>>  
>> -  
>> +  
>> +
>
> 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 postrm script is called after the package's
>> +  files have been removed or replaced.  The package
>> +  whos

Bug#504880: Disambiguate "installed" for packages

[Steve Langasek]

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 @@
>   
>  
>   
> -   Sometimes, a package requires another package to be installed
> -   and configured before it can be installed. In this
> -   case, you must specify a Pre-Depends entry for
> -   the package.
> +   Sometimes, a package requires another package to be unpacked
> +   and configured before it can be unpacked.  In this
> +   case, the dependent package must specify this dependency in
> +   the Pre-Depends 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.)

> +   The package will not yet be unpacked, so
> +   the preinst script cannot rely on any files
> +   included in its package.  Only essential packages and
> +   pre-dependencies (Pre-Depends) 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.
>   

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 postinst script may be called in the following
> +   ways:
> +   
> + postinst configure
> +   most-recently-configured-version
>   
> - conflictor's-prerm remove
> - in-favour package
> - new-version
> +   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.
>   

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

> +   unpacked in some error situations.
> + 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 prerm script failed,
> + foo's postinst abort-remove would be called with
> + bar only "Half-Installed".
> +   
>   
> -   
> +   
> + 

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?

> + 
> +   The postrm script may be called in the following
> +   ways:
> +   
> + postrm remove
> + postrm purge
> + old-postrm upgrade
> +   new-version
> + disappearer's-postrm disappear
> + overwriter overwriter-version
>   
> - new-postrm abort-install
> - old-version
> +   The postrm script is called after the package's
> +   files have been removed or replaced.  The package
> +   whose postrm is being called may have
> +   previously been deconfigured and only be unpacked, at which
> +   point subsequent package changes do not cons

Bug#504880: Disambiguate "installed" for packages

[Raphael Hertzog]

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.

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

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
Description: Digital signature

Bug#504880: Disambiguate "installed" for packages

[Bill Allombert]

On Mon, Jul 26, 2010 at 03:39:30PM -0700, Russ Allbery wrote:
> Jonathan Nieder  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
> >>
> >> -  ensuring that only one MTA can be installed at any one
> >> +  ensuring that only one MTA can be unpacked at any one
> >>time.  See  for more information about this
> >>example.
> >>
> 
> > 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. 

Imagine a large red swirl here. 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: mail-transport-agent (Re: Bug#504880: Disambiguate "installed" for packages)

[Russ Allbery]

Jonathan Nieder  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 (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: mail-transport-agent (Re: Bug#504880: Disambiguate "installed" for packages)

[Jonathan Nieder]

Russ Allbery wrote:
> Jonathan Nieder  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



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Jonathan Nieder]

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.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Jonathan Nieder  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
>>  
>> -ensuring that only one MTA can be installed at any one
>> +ensuring that only one MTA can be unpacked at any one
>>  time.  See  for more information about this
>>  example.
>>  

> 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 (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Jonathan Nieder]

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 preinst failures.
[...]
> When one binary package declares that it breaks another,
> dpkg will refuse to allow the package which
> -   declares Breaks be installed unless the broken
> +   declares Breaks 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
>   
> - ensuring that only one MTA can be installed at any one
> + ensuring that only one MTA can be unpacked at any one
>   time.  See  for more information about this
>   example.
>   

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 postrm
  upgrade 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:
new-postrm abort-upgrade
  old-version

- Called before unpackaging the new package as part of the
+ Called before unpacking the new package as part of the
  error handling of preinst failures.  May assume
  the same state as preinst can assume.

@@ -4776,7 +4776,7 @@ Build-Depends: foo [linux-any], bar [any-i386], baz 
[!linux-any]

  When one binary package declares that it breaks another,
  dpkg will refuse to allow the package which
- declares Breaks be unpacked unless the broken
+ declares Breaks to be unpacked unless the broken
  package is deconfigured first, and it will refuse to
  allow the broken package to be reconfigured.

-- 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

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

 

- Sometimes, a package requires another package to be installed
- and configured before it can be installed. In this
- case, you must specify a Pre-Depends entry for
- the package.
+ Sometimes, unpacking one package requires that another package
+ be first unpacked and configured.  In this case, the
+ dependent package must specify this dependency in
+ the Pre-Depends control field.

 

@@ -3683,7 +3683,7 @@ Checksums-Sha256:
 

  Broadly speaking the preinst is called before
- (a particular version of) a package is installed, and the
+ (a particular version of) a package is unpacked, and the
  postinst afterwards; the prerm
  before (a version of) a package is removed and the
  postrm afterwards.
@@ -3767,111 +3767,177 @@ Checksums-Sha256:

 

- 
-   
- new-preinst install
-   
-   
- new-preinst install old-version
-   
-   
-   new-preinst upgrade old-version
-   
-   
-   old-preinst abort-upgrade
-   new-version
-   
- 
+ 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 new- are the scripts from the new version of a
+ package being installed, upgraded to, or downgraded to.  Script
+ names preceded by old- are the scripts from the old
+ version of a package that is being upgraded from or downgraded
+ from.
+   
 

- 
-   
-   postinst configure
-   most-recently-configured-version
-   
-   
-   old-postinst abort-upgrade
-   new-version
-   
-   
-   conflictor's-postinst abort-remove
-   in-favour package
-   new-version
-   
+ The preinst script may be called in the following
+ ways:
+ 
+   new-preinst install
+   new-preinst install
+ old-version
+   new-preinst upgrade
+ old-version

-   postinst abort-remove
+ The package will not yet be unpacked, so
+ the preinst script cannot rely on any files
+ included in its package.  Only essential packages and
+ pre-dependencies (Pre-Depends) 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.

+
+   old-preinst abort-upgrade
+ new-version

-   deconfigured's-postinst
-   abort-deconfigure in-favour
-   failed-install-package version
-   [removing conflicting-package
-   version]
+ Called during error handling of an upgrade that failed after
+ unpacking the new package because the postrm
+ upgrade 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.
+   This can happen if the new version of the package no
+   longer pre-depends on a package that had been partially
+   upgraded.
+ 

- 
+ 
+   
 

- 
-   
-   prerm remove
-   
-   
-   old-prerm upgrade
-   new-version
-   
-   
-   new-prerm failed-upgrade
-   old-version
-   
+ The postinst script may be called in the following
+ ways:
+ 
+   postinst configure
+ most-recently-configured-version

-   conflictor's-prerm remove
-   in-favour package
-   new-version
+ The files contained in the package will be un

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Jonathan Nieder  writes:
> Russ Allbery wrote:

>> I found the original awkward and hard to puzzle out.  How about this:
>> 
>>  
>>Since Depends 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.
>>  

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

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

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

>>In the case
>>  of prerm or other postinst
>>  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 prerm or other postinst
>   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 prerm or other postinst
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 (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Jonathan Nieder  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 (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Steve Langasek  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 Breaks, 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:


  When one binary package declares a conflict with another using
  a Conflicts field, dpkg will refuse to
  allow them to be unpacked on the system at the same time.  This
  is a stronger restriction than Breaks, 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.


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

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Jonathan Nieder]

Steve Langasek wrote:

> So I think it's better to say:
> 
>   This is a stronger restriction than Breaks, 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.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Steve Langasek]

On Wed, Jul 21, 2010 at 01:37:28PM -0700, Russ Allbery wrote:
> >>
> >>When one binary package declares a conflict with another
> >>  using a Conflicts field, dpkg 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 Breaks,
> >>  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 Breaks,
> > 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 Breaks, 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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#504880: Disambiguate "installed" for packages

[Jonathan Nieder]

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



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Jonathan Nieder  writes:
> Russ Allbery wrote:
>> Jonathan Nieder  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:

>   
>   preinst upgrade
>   
>   postrm upgrade
>   ... unpack other things ...
>   
>   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 (r...@debian.org)   



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Jonathan Nieder]

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


preinst upgrade

postrm upgrade
... unpack other things ...

postinst upgrade

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

[...]
> What I have now, given the above, is:
> 
>   
> Called during error handling of an upgrade that failed after
> unpacking the new package because the postrm
> upgrade 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.
>   

... 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:
> 
>   
> Called during error handling when prerm upgrade
> fails.  The new package will not yet be unpacked, and all
> the same constraints as for preinst upgrade apply.
>   

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.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Jonathan Nieder]

Russ Allbery wrote:

> I found the original awkward and hard to puzzle out.  How about this:
> 
>   
> Since Depends 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.
>   

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  writes:

>>> - The Depends field thus allows package maintainers
>>> - to impose an order in which packages should be configured.
>>> 
>
>> 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.

> 
>   The Depends field should also be used if the
>   postinst or prerm scripts
>   require the depended-on package to be unpacked or
>   configured in order to run.  In the case of postinst
>   configure, 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 prerm or other postinst
>   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 prerm or other postinst
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 Breaks,
>>  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 atte

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Russ Allbery  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 @@

 

- Sometimes, a package requires another package to be installed
- and configured before it can be installed. In this
- case, you must specify a Pre-Depends entry for
- the package.
+ Sometimes, a package requires another package to be unpacked
+ and configured before it can be unpacked.  In this
+ case, the dependent package must specify this dependency in
+ the Pre-Depends control field.

 

@@ -3674,7 +3674,7 @@ Checksums-Sha256:
 

  Broadly speaking the preinst is called before
- (a particular version of) a package is installed, and the
+ (a particular version of) a package is unpacked, and the
  postinst afterwards; the prerm
  before (a version of) a package is removed and the
  postrm afterwards.
@@ -3758,111 +3758,173 @@ Checksums-Sha256:

 

- 
-   
- new-preinst install
-   
-   
- new-preinst install old-version
-   
-   
-   new-preinst upgrade old-version
-   
-   
-   old-preinst abort-upgrade
-   new-version
-   
- 
+ 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 new- are the scripts from the new version of a
+ package being installed, upgraded to, or downgraded to.  Script
+ names preceded by old- are the scripts from the old
+ version of a package that is being upgraded from or downgraded
+ from.
+   
 

- 
-   
-   postinst configure
-   most-recently-configured-version
-   
-   
-   old-postinst abort-upgrade
-   new-version
-   
-   
-   conflictor's-postinst abort-remove
-   in-favour package
-   new-version
-   
+ The preinst script may be called in the following
+ ways:
+ 
+   new-preinst install
+   new-preinst install
+ old-version
+   new-preinst upgrade
+ old-version

-   postinst abort-remove
+ The package will not yet be unpacked, so
+ the preinst script cannot rely on any files
+ included in its package.  Only essential packages and
+ pre-dependencies (Pre-Depends) 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.

+
+   old-preinst abort-upgrade
+ new-version

-   deconfigured's-postinst
-   abort-deconfigure in-favour
-   failed-install-package version
-   [removing conflicting-package
-   version]
+ Called during error handling of an upgrade that failed after
+ unpacking the new package because the postrm
+ upgrade 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.

- 
+ 
+   
 

- 
-   
-   prerm remove
-   
-   
-   old-prerm upgrade
-   new-version
-   
-   
-   new-prerm failed-upgrade
-   old-version
-   
+ The postinst script may be called in the following
+ ways:
+ 
+   postinst configure
+ most-recently-configured-version

-   conflictor's-prerm remove
-   in-favour package
-   new-version
+ The files contained in the package will be unpacked.  All
+ package dependencies will at least be u

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Jonathan Nieder  writes:

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

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


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


which hopefully re-adds the specific information.

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

> 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 @@ 
>>  
>>
>>  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.
>> +postinst or prerm 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?

  
The Depends field should also be used if the
postinst or prerm scripts
require the depended-on package to be unpacked or
configured in order to run.  In the case of postinst
configure, 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 prerm or other postinst
actions, the package dependencies will be at least
unpacked or "Half-Installed".
  


>>  
>>When one binary package declares a conflict with another
>>using a Conflicts field, dpkg 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 Breaks,
>>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 Breaks,
>   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 (r...@debian.org)   



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Thank you very much for the detailed review!

Jonathan Nieder  writes:
> Russ Allbery wrote:

>>  
>> +  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 new- are the scripts from the new
>> +  version of a package being installed or upgraded.  Script names
>> +  preceeded by old- are the scripts from the old
>> +  version of a package that is being upgraded to a new version.
>> +

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


  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 new- are the scripts from the new version of a
  package being installed, upgraded to, or downgraded to.  Script
  names preceded by old- are the scripts from the old
  version of a package that is being upgraded from or downgraded
  from.


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
>> +  (Pre-Depends) 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
>   (Pre-Depends) 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
>   Pre-Depends 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:


  The package will not yet be unpacked, so
  the preinst script cannot rely on any files
  included in its package.  Only essential packages and
  pre-dependencies (Pre-Depends) 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.


> 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 postrm failed during the upgrade action.

> Getting wordy.  Maybe:

>   Called to recover from an upgrade that failed after
>   unpacking the new package because the old postrm
>   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 f

Bug#504880: Disambiguate "installed" for packages

[Jonathan Nieder]

Hi again,

Continuing where I left off.

>
>   Details of unpack phase of installation or upgrade
[...]
> @@ -4540,31 +4595,29 @@   
>   
>  
>   
> -   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 Depends 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.
>   

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

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

Is this removal intended?

[...]
> @@ -4588,12 +4642,16 @@ 
>  
> 
>   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.
> + postinst or prerm 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 postinst, 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 prerm, the package dependencies will be at
> + least unpacked or "Half-Installed".
> +   

So maybe something roughly like


  The Depends field should also be used if the
  postinst or prerm 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]


[1] In the case of postinst configure,
the depended-on packages will be unpacked and configured
before the script is run.  When postinst or
prerm 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]
> 
>  
> 
> - When the package declaring a pre-dependency is about
> - to be configured, the pre-dependency will be
> - treated as a normal Depends, 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 configured, the pre-dependency will be treated
> + as a normal Depends.  It will be considered
> + satisfied only if the depended-on package has been
> + correctly configured.  However, unlike
> + with Depends, Pre-Depends does not
> + permit circular dependencies to be broken.  If a circular
> + dependency is encountered while attempting to honor
> + Pre-Depends, the installation will be aborted.
> +   

Nice.

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

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 @@ 
>   
> When one binary package declares that it breaks another,
> dpkg will refuse to allow the package which
> -   declares Breaks be installed unless the broken
> +   declares Breaks be unpacked unless the broken
> package is dec

Bug#504880: Disambiguate "installed" for packages

[Jonathan Nieder]

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:
>   
>  
>   
> +   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 new- are the scripts from the new
> +   version of a package being installed or upgraded.  Script names
> +   preceeded by old- are the scripts from the old
> +   version of a package that is being upgraded to a new version.
> + 

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.

> +
> + 
> +   The preinst script may be called in the following
> +   ways:
> -   
> - 
> -   new-preinst install
> - 
> - 
> -   new-preinst install old-version
> - 
> - 
> - new-preinst upgrade old-version
> - 
> +   
> + new-preinst install
> + new-preinst install
> +   old-version
> + new-preinst upgrade
> +   old-version
> + 
> +   Only essential packages and pre-dependencies
> +   (Pre-Depends) 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
(Pre-Depends) 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
Pre-Depends 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 preinst script cannot rely
> +   on any files included in its package.
> + 
> +
> - 
> - old-preinst abort-upgrade
> - new-version
> - 
> -   
> -
> + old-preinst abort-upgrade
> +   new-version
> + 
> +   Called during error handling of an upgrade that failed after
> +   unpacking the new package because the
> +   old postrm failed during the upgrade action.

Getting wordy.  Maybe:

Called to recover from an upgrade that failed after
unpacking the new package because the old postrm
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.
> + 
> +   
> + 

 * 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 (Depends) 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
gua

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Colin Watson  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 @@

 

- Sometimes, a package requires another package to be installed
- and configured before it can be installed. In this
+ Sometimes, a package requires another package to be unpacked
+ and configured before it can be unpacked. In this
  case, you must specify a Pre-Depends entry for
  the package.

@@ -3674,7 +3674,7 @@ Checksums-Sha256:
 

  Broadly speaking the preinst is called before
- (a particular version of) a package is installed, and the
+ (a particular version of) a package is unpacked, and the
  postinst afterwards; the prerm
  before (a version of) a package is removed and the
  postrm afterwards.
@@ -3758,111 +3758,166 @@ Checksums-Sha256:

 

- 
-   
- new-preinst install
-   
-   
- new-preinst install old-version
-   
-   
-   new-preinst upgrade old-version
-   
-   
-   old-preinst abort-upgrade
-   new-version
-   
- 
+ 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 new- are the scripts from the new
+ version of a package being installed or upgraded.  Script names
+ preceeded by old- are the scripts from the old
+ version of a package that is being upgraded to a new version.
+   
 

- 
-   
-   postinst configure
-   most-recently-configured-version
-   
-   
-   old-postinst abort-upgrade
-   new-version
-   
-   
-   conflictor's-postinst abort-remove
-   in-favour package
-   new-version
-   
+ The preinst script may be called in the following
+ ways:
+ 
+   new-preinst install
+   new-preinst install
+ old-version
+   new-preinst upgrade
+ old-version

-   postinst abort-remove
+ Only essential packages and pre-dependencies
+ (Pre-Depends) 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 preinst script cannot rely
+ on any files included in its package.

+
+   

Bug#504880: Disambiguate "installed" for packages

[Ian Jackson]

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.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

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

Bug#504880: Disambiguate "installed" for packages

[Kurt Roeckx]

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




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Kurt Roeckx]

On Sat, Feb 14, 2009 at 12:16:16PM -0800, Russ Allbery wrote:
> Kurt Roeckx  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




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Kurt Roeckx  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 (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Kurt Roeckx]

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




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Raphael Hertzog  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]

 

- 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.
-   
-
-
-  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.
-
-
-   
- The Depends field thus allows package maintainers
- to impose an order in which packages should be configured.
+ Since Depends 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.
+   
+
+   
+ 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
+ postinst script, then the cycle will be broken at
+ that package; this ensures that all postinst
+ 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 postinst
+ scripts.

 

@@ -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 Depends field have been correctly
-   configured.
+   configured (unless there is a circular dependency as
+   described above).
  
 
  
@@ -4323,10 +4323,17 @@ Build-Depends: foo [!i386] | bar [!amd64]
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.
+   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
+   postinst and postrm, the
+   depended-on packages will be unpacked and configured
+   first.  (Note, however, that the postrm
+   cannot rely on any non-essential packages to be present
+   during the purge phase.)  In the case of
+   prerm, the depended-on package will at least
+   be unpac

Bug#504880: Disambiguate "installed" for packages

[Bill Allombert]

On Wed, Feb 11, 2009 at 08:27:57PM -0800, Russ Allbery wrote:
> Raphael Hertzog  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. 

Imagine a large red swirl here. 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Raphael Hertzog]

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/



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Raphael Hertzog  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 (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Kurt Roeckx]

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 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.
> + 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
> +postinst and postrm, the
> +depended-on packages will be unpacked and configured.
> +Note, however, that the postrm cannot rely on
> +any non-essential packages to be present during the
> +purge phase.  In the case of prerm,
> +the depended-on package will at least be unpacked (it might
> +be configured too, but you can't rely on it unless you use
> +Pre-Depends).
>   
>  
>   Recommends

This atleast states how I think it works.


Kurt




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Raphael Hertzog]

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/
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 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.
+		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
+postinst and postrm, the
+depended-on packages will be unpacked and configured.
+Note, however, that the postrm cannot rely on
+any non-essential packages to be present during the
+purge phase.  In the case of prerm,
+the depended-on package will at least be unpacked (it might
+be configured too, but you can't rely on it unless you use
+Pre-Depends).
 	
 
 	Recommends

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

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  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 (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#504880: Disambiguate "installed" for packages

[Raphael Hertzog]

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/



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#504880: Disambiguate "installed" for packages

[Colin Watson]

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   [EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#504880: Disambiguate "installed" for packages

[Raphael Hertzog]

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
Description: Digital signature

Bug#504880: Disambiguate "installed" for packages

[Colin Watson]

On Fri, Nov 07, 2008 at 09:26:05PM +0100, Kurt Roeckx wrote:
> On Fri, Nov 07, 2008 at 07:13:18PM +, 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   [EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#504880: Disambiguate "installed" for packages

[Kurt Roeckx]

On Fri, Nov 07, 2008 at 07:13:18PM +, 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




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#504880: Disambiguate "installed" for packages

[Colin Watson]

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   [EMAIL PROTECTED]
diff --git a/policy.sgml b/policy.sgml
index 7de382d..44ff374 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1034,8 +1034,8 @@
 	
 
 	
-	  Sometimes, a package requires another package to be installed
-	  and configured before it can be installed. In this
+	  Sometimes, a package requires another package to be unpacked
+	  and configured before it can be unpacked. In this
 	  case, you must specify a Pre-Depends entry for
 	  the package.
 	
@@ -3456,7 +3456,7 @@ Package: libc6
 
 	
 	  Broadly speaking the preinst is called before
-	  (a particular version of) a package is installed, and the
+	  (a particular version of) a package is unpacked, and the
 	  postinst afterwards; the prerm
 	  before (a version of) a package is removed and the
 	  postrm afterwards.
@@ -3835,7 +3835,7 @@ Package: libc6
 		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.
 		Part of the problem is due to what is arguably a
 		bug in dpkg.
@@ -3971,7 +3971,7 @@ Package: libc6
 		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).
 	
@@ -4413,7 +4413,7 @@ Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
 	
 	  When one binary package declares that it breaks another,
 	  dpkg will refuse to allow the package which
-	  declares Breaks be installed unless the broken
+	  declares Breaks be unpacked unless the broken
 	  package is deconfigured first, and it will refuse to
 	  allow the broken package to be reconfigured.
 	
@@ -4454,13 +4454,13 @@ Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
 	
   When one binary package declares a conflict with another
 	  using a Conflicts field, dpkg 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.
 	
 
 	
-	  If one package is to be installed, the other must be removed
-	  first - if the package being installed is marked as
+	  If one package is to be unpacked, the other must be removed
+	  first - if the package being unpacked is marked as
 	  replacing (see ) the one on the system,
 	  or the one on the system is marked as deselected, or both
 	  packages are marked Essential, then
@@ -4655,7 +4655,7 @@ Provides: mail-transport-agent
 Conflicts: mail-transport-agent
 Replaces: mail-transport-agent
 	
-	ensuring that only one MTA can be installed at any one
+	ensuring that only one MTA can be unpacked at any one
 	time.
 	
   
@@ -4887,7 +4887,7 @@ Replaces: mail-transport-agent
  
 	
 	  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
@@ -5023,7 +5023,7 @@ Replaces: mail-transport-agent
 	) to ensure that the user only installs one