Hi again,
Continuing where I left off.
> <sect id="unpackphase">
> <heading>Details of unpack phase of installation or upgrade</heading>
[...]
> @@ -4540,31 +4595,29 @@ <chapt id="relationships">
> </p>
>
> <p>
> - For this reason packages in an installation run are usually
> - all unpacked first and all configured later; this gives
> - later versions of packages with dependencies on later
> - versions of other packages the opportunity to have their
> - dependencies satisfied.
> + Since <tt>Depends</tt> only places requirements on the
> + configuration step, packages in an installation run are usually
> + all unpacked first and all configured later. This makes it
> + easier to satisfy all dependencies when multiple packages are
> + being upgraded.
> </p>
The new second sentence is less specific than the anthropomorphizing
original. Intended?
[...]
> - The <tt>Depends</tt> field thus allows package maintainers
> - to impose an order in which packages should be configured.
> </p>
Is this removal intended?
[...]
> @@ -4588,12 +4642,16 @@ <sect id="binarydeps">
>
> <p>
> The <tt>Depends</tt> field should also be used if the
> - <prgn>postinst</prgn>, <prgn>prerm</prgn> or
> - <prgn>postrm</prgn> scripts require the package to be
> - present in order to run. Note, however, that the
> - <prgn>postrm</prgn> cannot rely on any non-essential
> - packages to be present during the <tt>purge</tt>
> - phase.
> + <prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
> + require the package to be unpacked or configured in order
> + to run.
Huh?
postinst in the normal case requires the package being installed to be
unpacked and all its dependencies to be configured. prerm requires
the package being removed to be halfconfigured.
I think part of my confusion is because:
* this item is supposed to be about what the Depends field can
be used to accomplish, not what requirements postinst and
preinst have;
* before, “the package” meant the package depended on, but now
it means the package being installed or removed.
> In the case of <prgn>postinst</prgn>, the
> + depended-on packages will be unpacked and configured
> + first. (If both packages are involved in a dependency
> + loop, this might not work as expected; see the explanation
> + a few paragraphs back.) In the case
> + of <prgn>prerm</prgn>, the package dependencies will be at
> + least unpacked or "Half-Installed".
> + </p>
So maybe something roughly like
<p>
The <tt>Depends</tt> field should also be used if the
<prgn>postinst</prgn> or <prgn>prerm</prgn> scripts require
the package to be present in order to run. See the descriptions
of postinst and prem in section 6.5 for details.[1]
</p>
[1] In the case of <prgn>postinst</prgn> <tt>configure</tt>,
the depended-on packages will be unpacked and configured
before the script is run. When <prgn>postinst</prgn> or
<prgn>prerm</prgn> is called for some other reason, the
depended-on packages will have been unpacked and fully
configured at some point since they were last removed, but
they may have been deconfigured since then or even left
"Half-Installed" after a partial upgrade.
would be less confusing.
> @@ -4652,11 +4710,21 @@ Build-Depends: foo [linux-any], bar [any-i386], baz
> [!linux-any]
> </p>
>
> <p>
> - When the package declaring a pre-dependency is about
> - to be <em>configured</em>, the pre-dependency will be
> - treated as a normal <tt>Depends</tt>, that is, it will
> - be considered satisfied only if the depended-on
> - package has been correctly configured.
> + When the package declaring a pre-dependency is about to
> + be <em>configured</em>, the pre-dependency will be treated
> + as a normal <tt>Depends</tt>. It will be considered
> + satisfied only if the depended-on package has been
> + correctly configured. However, unlike
> + with <tt>Depends</tt>, <tt>Pre-Depends</tt> does not
> + permit circular dependencies to be broken. If a circular
> + dependency is encountered while attempting to honor
> + <tt>Pre-Depends</tt>, the installation will be aborted.
> + </p>
Nice.
> +
> + <p>
> + <tt>Pre-Depends</tt> are also required if the
> + <prgn>preinst</prgn> script depends on the named package.
> + It is best to avoid this situation if possible.
> </p>
This moves the instruction to above the warning, so the final
paragraph can emphasize that Pre-Depends should be avoided.
Makes sense.
> @@ -4696,7 +4757,7 @@ <sect id="breaks">
> <p>
> When one binary package declares that it breaks another,
> <prgn>dpkg</prgn> will refuse to allow the package which
> - declares <tt>Breaks</tt> be installed unless the broken
> + declares <tt>Breaks</tt> be unpacked unless the broken
> package is deconfigured first
Oh! That’s true, and a very useful clarification.
> , and it will refuse to
> allow the broken package to be reconfigured.
> </p>
> @@ -4749,7 +4810,7 @@ <sect id="conflicts">
> <p>
> When one binary package declares a conflict with another
> using a <tt>Conflicts</tt> field, <prgn>dpkg</prgn> will
> - refuse to allow them to be installed on the system at the
> + refuse to allow them to be unpacked on the system at the
> same time. This is a stronger restriction than <tt>Breaks</tt>,
> which just prevents both packages from being configured at the
> same time. Conflicting packages cannot be unpacked on the
Whoops.
This is a stronger restriction than <tt>Breaks</tt>,
which only prevents the broken package from being configured at
the same time as the breaking package is unpacked.
> @@ -4757,8 +4818,8 @@ <sect id="conflicts">
> </p>
>
> <p>
> - If one package is to be installed, the other must be removed
> - first. If the package being installed is marked as replacing
> + If one package is to be unpacked, the other must be removed
> + first. If the package being unpacked is marked as replacing
> (see <ref id="replaces">, but note that <tt>Breaks</tt> should
> normally be used in this case) the one on the system, or the one
> on the system is marked as deselected, or both packages are
Yep.
With whatever subset of the above changes seems appropriate, this
looks good to me.
Regards,
Jonathan
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100720235904.ga4...@burratino
