[Piuparts-devel] Bug#588041: Ready to tackle .. Feedback Solicited

[Scott Schaefer]

I have been thinking about this bug ("installing/removing the debs with
dpkg does not do dependency reordering" to refresh direct recipient's
minds) for some time, and am about ready to tackle it.

However, I would really appreciate some feedback from either Andreas
or Holger, or anyone who cares enough to read below, and has input ...

First, a summary of what I consider to the be "root issues":

1) The ability to specify > 1 .deb on piuparts command line is
infrequently (?) used, but is valuable enough that it is worth both:
    a) retaining, and
    b) make work "correctly",


2) In its most general form, piuparts runs tests on .deb files
F(1) ... F(n).  With n=1, it is "trivial" to build a
"dummy-metapackage" of all Depends: and Conflicts: and allow
apt-get to install, so that F(1) "should" install cleanly via
dpkg -i.

HOWEVER, for n>1, a number of issues arise.  I THINK (but have not
yet convinced myself), that all of the issues derive from one
fundamental:

For:
     x=1..n,
     y=1..n,
     x<>y:
           .deb file F(x) deb file may have Depends: on F(y),
           either directly, or "indirectly"/"recursively"

where "indirectly" is defined as F(x) Depends on package P, and
P Depends on F(y) directly, or "indirectly"


3) The precise behavior of piuparts when n>1 AND the .deb files
have some form of inter-dependency, is not (well) defined.

Example:
piuparts .... F(1) F(2)

If F(1) Depends on F(2), then the current version of the package
specified by F(2) is installed FROM THE ARCHIVE (since Depends: F(2)
is added to the dummy-metapackage which apt-get installs.]

This also, of course, causes the subsequent dpkg -i F(2) to be either
NOP [version in archive is >= version in F(2)], or an UPGRADE, rather
than a "new" install.

The user may or may not have expected these behaviors.  Certainly if
they are a developer or knowledgeable maintainer of both F(1), F(2)
one could reasonably assume they expected that the F(2) deb file
would be installed in order to satisfy the F(1) Depends ...
(this appears to be the cause of Andreas' original bug filing,
and what his proposed solution would achieve).

As much as I prefer to unambiguously define the "correct" behavior
FIRST, I am going to jump to listing the most reasonable solutions
from my perspective:

1) Treat n>1 as series of individual piuparts commands, each with
n=1.  Save the chroot after first run if not already saved.
That is ...

piuparts .... F(1) F(2) F(3)

is effectively treated as

piuparts .... -s <temp-filename> F(1)
piuparts .... -b <temp-filename> F(2)
piuparts .... -b <temp-filename> F(3)

Ugly, but simple.  OK, very ugly, and not very useful either :-)
Luckily, I am going from least-reasonable to most-reasonable :-))


2) Add just enough code to detect inter-dependencies, and generate
error message, directing user to re-order the command-line deb files,
probably with some "useful" to "complete" hints as to the "correct"
ordering

Not particularly elegant.  However, this may be the best solution
given resource constraints, design tradeoffs, and usage patterns.


3) Andreas' solution; load .deb files to temp directory and use apt-get,
causing it to prefer the temp directory via source.list entry, and
specific version #s.

IMHO (and seemingly the reason for Holger's response), the biggest
problem with this solution is that it makes determining which of the
.deb files was the cause of any error(s) to be extremely difficult,
if not impossible (since all the piuparts 'broken' and 'warning'
tests are designed around before/after install/upgrade of a SINGLE
.deb file)

OTOH, this may be exactly what the typical user who runs piuparts
with a .changes file to supply >1 .deb files for testing desires
and/or would find useful.


4) Finally, I have an uncompleted design spec for a solution that
involves:

a) Modifying the logic which creates the dummy-metapackage to NOT
add Depends iwhere package-name is one of command-line .deb files,

b) Performing a preliminary re-ordering of the command-line .deb files
based on direct inter-dependencies, and

c) Use of initial apt-get WITH --simulate option to refine/complete
the determination of order in which to install/remove/purge/upgrade
each command-line .deb file.

The advantage to this solution is that it (theoretically) allows all
the existing 'broken' and 'warning' tests to run unmodified.  In fact,
it makes the single .deb file on command line (n-1), just a special case
of the multi-file (n>1) logic.

The disadvantage of course, is that it is both more complex, and as-yet
unknown to work.

I am hoping to get some feedback over weekend.  If none, I will try to
complete design spec and submit for further comment.