(switching topics; sorry for the cognitive dissonance)
Steve Langasek wrote:
> Taken in sum, there is a cost to that documentation.
Thanks for a nice summary.
> On Sat, Mar 05, 2011 at 06:26:27PM -0600, Jonathan Nieder wrote:
>> Bug#593177 brings the possibility of change. In the extreme case the
>> meaning of Pre-Depends could change to "the depended-on package and
>> its dependencies must be configured at the currently unpacked
>> version", which would make upgrade impossible in the following case.
>
>> Luckily, bug#593177 can probably be addressed with less dramatic
>> changes.
>
> Yes, frankly I don't know why you're even presenting that as an option; I
> don't believe anyone involved in that bug report is arguing for such a
> thing.
That's true (for obvious reasons --- nobody likes breakage). And
probably there is a better potential rule that I should have been
keeping in mind. So let's figure out what it is.
The current rules are designed to make it hard to get into trouble
and to ensure the relevant dependencies for any package management
operation are easy to calculate. Here's a reminder, so I can keep
them in mind:
- all essential packages must always be unpacked and usable;
- if package A is unpacked, all its pre-dependencies are unpacked
and usable;
- each time package A becomes configured, all its dependencies
are configured (assuming there are no dependency loops). But
between configuration times, those packages can become just
unpacked and usable.
I am using "unpacked and usable" as a short way to say "was once
configured and has not been removed since then". In the case of
essential packages, that really does means "usable", but for other
packages it generally will not --- that is the topic of this bug.
I can use non-essential packages for everyday tasks because in
the normal state, _all_ packages are configured at the current
version. The configuration-time constraint above ("each time package
A becomes configured, all its dependencies are configured") is needed
for postinst to work reliably at all.
And "all its dependencies" ideally ought to take into account the
dependencies' dependencies, too. During an ordinary upgrade (unpack
everything, configure the mess), it does. During error recovery it
does not --- scanning recursively past packages that are already fully
configured would presumably be too constraining and too slow. [1]
Reasonable so far? Barring bugs, that is how dpkg currently works.
This bug is about the analogous problem for preinst. Presumably
requiring that each pre-dependency is fully configured as a
precondition for "dpkg --unpack" should be good enough, right?
Ideally I would want to say something analogous to the case for
postinst --- that scenarios like [1] are possible but (1) they will
not come up during an ordinary "unpack everything without
unsatisfied pre-dependencies, configure the mess, repeat" upgrade and
(2) they are easy to recover from by manual or high-level package
manager intervention.
Unfortunately (1) is not true at all. Is there a better simple
upgrade path?
Hoping that is clearer,
Jonathan
[1] If I do:
echo 'Package: old-library' >oldlib.control
echo 'Package: new-library' >newlib.control
printf '%s\n' \
'Package: helper' \
'Version: 1' \
'Depends: old-library' >helper1.control
printf '%s\n' \
'Package: helper' \
'Version: 2' \
'Depends: new-library' >helper2.control
printf '%s\n' \
'Package: helper-metapackage' \
'Depends: helper' >metapackage.control
printf '%s\n' \
'Package: foo' \
'Depends: helper-metapackage' >foo.control
for i in *.control
do
equivs-build $i
done
and then try
# Install helper-metapackage.
dpkg -i old-library_* helper_1* helper-metapackage_*
# Start to upgrade helper, but do not finish installing
# its dependencies.
dpkg --unpack helper_2*
# Install foo.
dpkg -i foo_*
No error. Now imagine that foo's postinst uses the "helper" command
--- it would presumably fail. Which is fine --- the admin or
high-level package manager can notice something is broken and install
new-library to fix it.
Of course in edge cases that really would not be fine at all. If what
the helper package provides is something like the "test" utility and
it only gets used like
if ! fancy-utility
then
...
fi
then in this scenario there could be some subtle problems.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
