Re: Bug#504880: Disambiguate "installed" for packages
Russ Allbery wrote:
> I found the original awkward and hard to puzzle out. How about this:
>
> <p>
> Since <tt>Depends</tt> only places requirements on the order in
> which packages are configured, packages in an installation run
> are usually all unpacked first and all configured later. [*]This
> allows multiple packages to be upgraded in one unpack and
> configure step even if some packages being upgraded have
> versioned dependencies on the upgraded versions of other
> packages involved in the installation run.
> </p>
The rationale makes sense. The second sentence, which I have marked
with *, is getting a bit long and still does not have the charm of the
original.
> which hopefully re-adds the specific information.
Taking a step back, I can think of a few reasons to unpack everything
at the start of a dpkg run:
1. It lumps output to the filesystem, which would be friendly to
disks if we didn’t use fsync().
2. Most packages work fine without any need to be configured. So
this makes the new packages available for use by local users
as early as possible.
3. Dependency resolution is very simple, since unpacking order
is not constrained. If Pre-Depends do not permit unpacking one
of the packages, dpkg can error out right away.
4. If there is a dependency loop, some packages will have to work
well enough to satisfy dependencies (for postinst) without being
configured. If all packages involved are unpacked already, there
is no need to do anything special to satisfy that kind of
dependency.
I had thought the original was hinting at this fourth reason, but
after rereading it I think I must have been imagining that. The
second and third reasons look to be more important, anyway.
I would suggest removing the confusing sentence. It would be lovely
to document the reasons for this detail of dpkg’s design somewhere,
but it does not make the policy any more readable.
> Jonathan Nieder <jrnieder@gmail.com> writes:
>>> - The <tt>Depends</tt> field thus allows package maintainers
>>> - to impose an order in which packages should be configured.
>>> </p>
>
>> Is this removal intended?
>
> Yes, it seems to just duplicate the first sentence of the paragraph above
> and the description of Depends later on.
Thanks; makes sense.
> <p>
> The <tt>Depends</tt> field should also be used if the
> <prgn>postinst</prgn> or <prgn>prerm</prgn> scripts
> require the depended-on package to be unpacked or
> configured in order to run. In the case of <tt>postinst
> configure</tt>, the depended-on packages will be unpacked
> and configured first. (If both packages are involved in a
> dependency loop, this might not work as expected; see the
> explanation a few paragraphs back.)
Nice.
> In the case
> of <prgn>prerm</prgn> or other <prgn>postinst</prgn>
> actions, the package dependencies will be at least
> unpacked or "Half-Installed".
Again, it will have been unpacked at some version and not removed
since then, right? A very careful person can take advantage of
that. Stealing your wording from elsewhere:
In the case
of <prgn>prerm</prgn> or other <prgn>postinst</prgn>
actions, the package dependencies will be at least
unpacked, except they may be only "Half-Installed"
if an upgrade of the dependency failed.
>> Whoops.
>
>> This is a stronger restriction than <tt>Breaks</tt>,
>> which only prevents the broken package from being configured at
>> the same time as the breaking package is unpacked.
>
> I believe what I wrote is more correct than what you wrote. What do you
> think is wrong about it which prompts the "whoops"? Breaks allows both
> packages to be unpacked at the same time, but only one of the two packages
> can be configured at the same time. Configuring one package will result
> in deconfiguring the other.
Breaks is an asymmetrical relationship: the constraint it imposes
is that the breaking package cannot be unpacked at the same time as
the broken package is configured.
Survey of dpkg code involving Breaks:
* depisok will notice a package broken by a package to be unpacked.
(If the to-be-broken package is half-configured, it is left alone.)
* check_breaks uses depisok to determine whether to deconfigure a
broken package or perhaps error out. This is used when unpacking a
new package (see process_archive).
* predeppackage and check_conflict use depisok to handle Pre-Depends
and Conflicts, respectively.
* process_archive uses depisok directly to check Pre-Depends for
all packages and reverse-(Depends/Pre-Depends/Recommends) for
disappearing packages.
* breakses_ok checks reverse-Breaks for a particular package, to
decide whether to error out when attempting to configure it.
> (At least. I think under normal
> circumstances the broken package is then removed, although I'm not sure
> since Policy never says that. All Policy says will happen is that it will
> be deconfigured.)
Right. dpkg -B will deconfigure the package, but higher-level tools
tend to be more aggressive on the assumption that a broken package is
a useless package.
Reply to: