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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org