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..
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
