switching the default solver for the library

Hi folks,

after rolling out the new solver for the command-line I believe
we may have fixed the last fixable API backward compatibility
issue and can soon swap the default in the library, so _all_
frontends will use it.

# gaps

There are still various differences:

1. The AutoInst argument to MarkInstall() no longer works,
   no dependencies are marked for install and you need to
   call pkgProblemResolver (previously you only had to do
   it if there were conflicts; but API wise that looks the
   same).
2. The order of Mark*() calls no longer matters.

3. Running the solver multiple times has not been tested
   extensively. Particularly since the order does not matter
   things like:

       MarkInstall("foo")
       Run Solver
       MarkDelete("bar") # oops it installed bar, i don't want that
       Run Solver

    may have different behavior.

4. Some of the test cases fail for other reasons (see solver3.broken)

   The testing scenarios are quite ... minimal and do not reflect
   real world scenarios well. In real world scenarios, the problems
   do not occur and we did not find any worse results after months
   of triaging real world suggested regressions.

# testing

Library users should experiment with porting now by putting

    APT::Solver "3.0";

in apt.conf and seeing if stuff works.

# transition

After the default has switched, clients may request the old
version instead by running

    _config->Set("APT::Solver", "internal");

- a more appropriate general purpose mechanism for selecting
"tested" apt library versions and emulation of them is being
planned, such as:

    pkgInitConfig(..., "1.0", "3.0");

to declare that "1.0" is the earliest and "3.0" is the latest
tested version. However, that is a fairly broad switch of all
APT behavior.

# ripping it out

As we continue transitioning to the new solver, the next step
is to disable most of the state tracking in DepCache (what is
a broken dependency, what is satisfied), which is most of the
overhead, as it runs for _all_ dependency objects in the cache.

Conservative timeline:

(keep in mind odd versions are development series of the next
version, 3.9.x is the 4.0 series)

June 2026 (3.3.2): Migrate library to new solver
May  2027 (3.5.x): Deprecate the old solver
May  2028 (3.7.x): ...
May  2029 (3.9.x): Remove the old solver

Assuming we manage to release Debian releases in May 2027 and
May 2029, otherwise this can move back 6 months easily.

Optimistic timeline: If we do not see issues in the next
5 months, we could accelerate this to:

June 2026 (3.3.2):      Migrate library to new solver
November 2026 (3.3.x):  Deprecate the old solver
May  2027 (3.5.x):      Remove the old solver

This will greatly simplify optimizing the depcache performance.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en