[Piuparts-devel] Bug#526045: Preliminary Patch: Input Welcome

[Scott Schaefer]

Thanks, Holger ... your input '... dependency resolver, which doesnt 
take alternative depends into consideration.' led me to directly what I 
hope is the solution.

I have a patch for this issue on which I have run some preliminary tests.

I am busy tomorrow (Friday, Jun 3) and Saturday, so I do not expect to 
get back to this until Sunday.  However, I would appreciate input anyone 
may have regarding my solution:

Unfortunately, it is probably more useful to attempt to describe than to 
submit the patch;  I do not have a master/slave environment setup yet, 
and chose to "kluge" piuparts-master in order to force 
PackageDB._compute_package_states() to run, and then added routine to 
dump every package name/state.

The root cause of the problem is, indeed, that the current 
Package._parse_dependencies() routine always returns a list of 
SINGLE-PACKAGE-NAME(S), even when the package control file specifies 
alternatives.  Example:

debian/control from piwi-0.8+20041206, currently reported by piuparts as 
'dependency-does-not-exist', due to: 'dependency apache is /unknown'/:

Depends: ${perl:Depends}, apache | apache-ssl | apache-perl | httpd, 
mysql-client | postgresql-client, libapache-dbi-perl, libdbd-mysql-perl| 
libdbd-pg-perl, libdate-calc-perl

The parse routines (correctly) recognize this as six dependencies:
    [0] ${perl:Depends},
    [1] apache | apache-ssl | apache-perl | httpd,
    [2] mysql-client | postgresql-client,
    [3] libapache-dbi-perl,
    [4] libdbd-mysql-perl | libdbd-pg-perl,
    [5] libdate-calc-perl

However, _parse_dependencies FLATTENS the list in elements [1], [2], and 
[4] by simplistically selecting the first alternative from the control 
file; i.e. the list of depends that is actually processed from this 
example is:

    [0] ${perl:Depends},
    [1] apache
    [2] mysql-client
    [3] libapache-dbi-perl,
    [4] libdbd-mysql-perl
    [5] libdate-calc-perl

I have introduced code to return and process the unflattened list.  The 
design goal is to replace each list element with the name of the "best" 
alternative, and to leave all other existing logic in place.  While this 
is sub-optimal, it seems a major improvement over blindly selecting the 
first alternative from the control file.

The algorithm used to select the "best" alternative is:

    1) Prefer first alternative in state "essential-required"
    2) If no "essential-required" alternatives, prefer first alternative 
in state "successfully-tested"
    3) Otherwise, prefer first alternative in state 
"waiting-to-be-tested" IF NO REMAINING alternatives are in one of the 
"unknown/fail" states

I have introduced two new states:

a) "unknown-preferred-alternative": equivalent of "unknown", this defers 
calculation of this package's state, since one or more of its 
alternative depends are "unknown" (or "unknown-preferred-alternative"), 
and no alternative is either "essential-required" or 
"successfully-tested".  The alternatives will be re-tested on subsequest 
pass.

b) "no-dependency-from-alternatives-exists": if none of the alternatives 
can be found in the archive.


Potential problems:

1) We will test and fail when >=1 "successfully-tested" alternative is 
found, but a different alternative is selected by the apt 
dependency-resolution algorithm during test run,

2) We will produce a false positive "Dependency failed/cannot be 
tested", when the state could/should be 
"waiting-for-dependency-to-be-tested" (in the case that any alternative 
has "failed", but the alternative selected by the apt 
dependency-resolution algorithm is "waiting-to-be-tested"

3) Finally, there may be too much code which depends on 
"no-dependency-exists", so that it would make sense to change 
"no-dependency-from-alternatives-exists" back to simply 
"no-dependency-exists".  I see benefit in keeping them as separate states..