| Age | Commit message (Collapse) | Author |
|---|
|
With b4450f1dd6bca537e60406b2383ab154a3e1485f we dropped what we
calculated here later on and now that we don't need it in the meantime
either we can just skip the busy work by default and expect dpkg to do
the right thing dropping also our little "last explicit configures"
removal trick introduced in b4450f1dd6bca537e60406b2383ab154a3e1485f.
This enables the last of a bunch of previously experimental options,
some of them existing still, but are very special and hence not really
worth documenting anymore (especially as it would need to be rewritten
now entirely) which is why the documentation is nearly completely
dropped.
The order of configuration stanzas in the simulation code changes
slightly as it isn't concerning itself with finding the 'right' order,
but any order is valid anyhow as long as the entire set happens in the
same call.
|
|
This doesn't allow all tests to run cleanly, but it at least allows to
write tests which could run successfully in such environments.
Git-Dch: Ignore
|
|
Gbp-Dch: ignore
|
|
We use test{success,failure} now all over the place in the framework, so
its only consequencial to do this in the situations in which we test for
a specific output as well.
Git-Dch: Ignore
|
|
|
|
Commit 9ec748ff103840c4c65471ca00d3b72984131ce4 from Feb 23 last year
adds a version check after 8daf68e366fa9fa2794ae667f51562663856237c
added 8 days earlier negative points for breaks/conflicts with the
intended that only dependencies which are satisfied propagate points
(aka: old conflicts do not).
The implementation was needlessly complex and flawed through preventing
positive dependencies from gaining points like they did before these
commits making library transitions harder instead of simpler. It worked
out anyhow most of the time out of pure 'luck' (and other ways of
gaining points) or got miss attributed to being a temporary hick-up.
Closes: 774924
|
|
Previously, we had a start and a done of the calculation printed by
higher-level code, but this got intermixed by progress reporting from an
external solver or the output of autoremove code…
The higherlevel code is now only responsible for instantiating a
progress object of its choosing (if it wants progress after all) and the
rest will be handled by the upgrade code. Either it is used to show the
progress of the external solver or the internal solver will give some
hints about its overall progress. The later isn't really a proper
progress as it will jump forward after each substep, but that is at
least a bit better than before without any progress indication.
Fixes also the 'strange' non-display of this progress line in -q=1, while
all others are shown, which is reflected by all testcase changes.
|
|
Prevents that "old" dependencies have an influence in the scoring.
With positive dependencies this is usually not a problem, but negative
dependencies can linger around for a long time.
|
|
versioned -dev packages like db and boost have the problem of no
dependencies which would give them a competitive advantage against an
older incarnation of the -dev package, so they tend to be kept back
until the old version is removed from the archive, which, if the user
has older releases in its sources can take a long time (or never happens).
The newer version has a conflicts/breaks against the older one, but the
older one hasn't against the newer, so by giving via the conflicts the
older one a reduced score the newer one can win if there is no other
reason to keep it. If both have a conflict against each other the
scoring will cancel itself out, so no harm done.
This gives "action" a slightly bigger edge in breaks/conflicts cases
than before, but holding back isn't a really good solution anyway.
|
