apt/apt-pkg/algorithms.cc, branch 1.1.exp1Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.1.exp12014-04-11T11:45:52Zconsider priorities only for downloadable pkgs in resolver2014-04-11T11:45:52ZDavid Kalnischkiesdavid@kalnischkies.de2014-04-11T11:33:31Zurn:sha1:4cd4a2e7033a2af214be1d830b56fab719088b7a
A package which can't be downloaded anymore is very likely dropped from
a release and can therefore no longer be 'standard' (or similar). We
therefore do not grant points for them anymore and demote them to
prio:extra instead which helps other packages breaking them away even if
they have a lower priority.
The testcase was initially created by Michael Vogt and just amended.
cleanup headers and especially #includes everywhere2014-03-13T12:58:45ZDavid Kalnischkiesdavid@kalnischkies.de2014-03-05T21:11:25Zurn:sha1:453b82a388013e522b3a1b9fcd6ed0810dab1f4f
Beside being a bit cleaner it hopefully also resolves oddball problems
I have with high levels of parallel jobs.
Git-Dch: Ignore
Reported-By: iwyu (include-what-you-use)
warning: useless cast to type A [-Wuseless-cast]2014-03-13T12:58:45ZDavid Kalnischkiesdavid@kalnischkies.de2014-02-27T01:18:11Zurn:sha1:e788a834ce421042e727b72e43177edaa47e53a7
Git-Dch: Ignore
Reported-By: gcc -Wuseless-cast
check version before adding scores in resolver2014-03-13T12:57:34ZDavid Kalnischkiesdavid@kalnischkies.de2014-02-23T21:24:27Zurn:sha1:9ec748ff103840c4c65471ca00d3b72984131ce4
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.
do not do the same looping twice2014-03-13T12:57:34ZDavid Kalnischkiesdavid@kalnischkies.de2014-02-15T13:47:24Zurn:sha1:cb4b85b0bdba6a0c43ca62259dcd35fccd38a45a
Git-Dch: Ignore
propagate a negative score point along breaks/conflicts2014-03-13T12:57:34ZDavid Kalnischkiesdavid@kalnischkies.de2014-02-15T12:38:39Zurn:sha1:8daf68e366fa9fa2794ae667f51562663856237c
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.
Fix typos in documentation (codespell)2014-02-22T17:34:33ZMichael Vogtmvo@debian.org2014-02-22T17:34:33Zurn:sha1:1e3f4083db29bba600b9725e9456b0e140975c99Move ListUpdate/AquireUpdate into update.{cc,h}2013-10-05T10:22:55ZMichael Vogtmvo@debian.org2013-10-05T10:22:55Zurn:sha1:d428d131a29a08fa7c1d95b98b684fb2ebb554c0
This moves the ListUpdate/AquireUpdate out of the "catch-all"
algorithm.{cc,h} file into its own update.{cc,h}
* move upgrade releated code into upgrade.{cc,h}2013-10-05T10:15:03ZMichael Vogtmvo@debian.org2013-10-05T10:15:03Zurn:sha1:82e369c4b93b5b81db7988ab377a3c5bd388268e
The upgrade releated code is moved into upgrade.{cc,h} and
all pkg*Upgrade* prototypes are included in algorihms.h to
avoid breaking API (unless build with APT_9_CLEANER_HEADERS).
cleanup upgrade API some more (thanks for the feedback from David)2013-10-05T09:54:08ZMichael Vogtmvo@debian.org2013-10-05T09:54:08Zurn:sha1:5ca0cf51194422fb0f094bbf5e61e9f5eb57f013