| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Highlights:
- test-bug-618848-always-respect-user-requests: (Do not) Support 3.0 solver
A manually installed package is never removed just because we request
the removal of its dependency in solver3.
- test-bug-657695-resolver-breaks-on-virtuals: Support 3.0 solver
For manually installed packages, solver 3.0 would require some
new xserver-xorg-video-driver to Conflict+Replace+Provides the
old one (once the logic is implemented), but that does seem
reasonable.
- test-bug-720597-build-dep-purge: Support 3.0 solver
This needs a simple aptmark auto because pkga is removed by the
build-dep. But further adjustments are necessary because it weirdly
tested for no autoremovable packages before installing pkgc.
- test-bug-960705-*: Support 3.0 solver
Bit awkward to deal with; notably the protect to conflict doesn't
actually work anymore and that is a feature these days.
|
| |
|
|
|
|
| |
dpkg stumbles over these (#844300) and we haven't dropped 'easier'
removes to be implicit and to be scheduled by dpkg by default so far
so we shouldn't push the decision in such cases to dpkg either.
|
| |
|
|
|
|
|
|
|
|
|
| |
Our old idea was to look for the first package which would be "touched"
and take this as the package dpkg is talking about, but that is
incorrect in complicated situations like a package upgraded to/from
multiple M-A:same siblings installed.
As we us the progress report to decide what is still needed we have to
be reasonabily right about the package dpkg is talking about, so we jump
to quite a few loops to get it.
|
|
|
The user has to approve the removal of a crossgraded package as it might
be needed to remove it (temporarily) in the process, but in most cases
we can happily avoid it and let dpkg unpack over it skipping the
remove. This has some effects on progress reporting and how deal with
selections through which makes this a tiny bit complicated.
|
