Hi, I put Jessica and Ralf in CC because they are the solver experts. :)
On Wed, 8 Jul 2020 18:27:54 +0200 Adam Borowski <kilob...@angband.pl> wrote:
> This problem can't possibly be caused by elogind. A package may cause a
> problem only if:
> 1. some of its code is actually run (preinst, postinst, payload), or
> 2. it's the first alternative and the solver uses "first alternative only"
> or is otherwise unable to use the full solutions space
>
> The docs say:
> 'aspcud' resolver which (in contrast to apt and aptitude) is a real
> solver (in the math sense) and will thus always find a solution if a
> solution exists.
>
> Given a set of packages A containing package X, if A - X contains a
> solution, A with X also does -- ie, no relations declared by X (Breaks,
> Conflicts, Depends, Provides, ...) may possibly invalidate that solution.
>
> And we have:
> * unstable: apt resolver, doesn't even consider libelogind0
> * experimental: aspcud, supposed to be a full solver
>
> Thus, it looks to me like a problem in apt-cudf, almost surely not in the
> solver itself but in its integration with apt.
I managed to find out where the problem comes from. The problem is indeed not
aspcud but apt-cudf. Apt transforms the problem into the EDSP format, and
libelogind0 looks like this:
Package: libelogind0
Architecture: amd64
Version: 243.7-1+debian1
APT-ID: 7784
Multi-Arch: same
Source: elogind
Source-Version: 243.7-1+debian1
Priority: optional
Section: libs
APT-Release:
o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64
APT-Pin: 500
APT-Candidate: yes
Depends: libc6 (>= 2.30), libcap2 (>= 1:2.10)
Conflicts: libsystemd0, systemd
Replaces: libsystemd0
Provides: libsystemd0 (= 243.7)
That's all good and seems fine. It is then the job of apt-cudf to turn the EDSP
format into CUDF format which is understood by common CUDF solvers. And that's
where things go wrong, because the CUDF stanza for libelogind0 reads:
package: libelogind0%3aamd64
version: 23683
depends: libc6%3aamd64 >= 16972 , libcap2%3aamd64 >= 25386
conflicts: systemd%3aamd64 , --virtual-systemd%3aamd64 , systemd%3aamd64 ,
--virtual-systemd%3aamd64 , libelogind0%3aamd64
provides: libelogind0 , --virtual--versioned-libsystemd0%3aamd64 = 23682 ,
--virtual-libsystemd0%3aamd64 = 2147483646
installed: true
priority: optional
name: libelogind0
architecture: amd64
number: 243.7-1+debian1
source: elogind
sourcenumber: 243.7-1+debian1
sourceversion: 23683
replaces: libsystemd0 , --virtual-libsystemd0
native: 1
type: bin
apt-pin: 500
apt-id: 7784
apt-candidate: true
section: libs
Looking into the conflicts field, the conflict with libsystemd0 doesn't exist
anymore. This explains why aspcud happily adds libelogind0 into the solution:
because it wasn't told, that it conflicts with libsystemd0. If you want to find
out the above at home, just run sbuild with --build-deps-failed-commands=%s
like so:
$ sbuild -d unstable --extra-repository='deb http://deb.debian.org/debian
experimental main' --extra-repository='deb-src http://deb.debian.org/debian
experimental main' --build-dep-resolver=aspcud --build-deps-failed-commands=%s
hplip_3.20.6+dfsg0-1
and then after build-deps failed to install, run the following to create an
EDSP file:
$ APT_EDSP_DUMP_FILENAME=/tmp/dump.edsp apt-get install
--with-source=resolver-* --simulate --solver=dump -o
APT::Solver::Strict-Pinning=false sbuild-build-depends-main-dummy
You can then copy the EDSP file out of the schroot and put it into apt-cudf:
$ apt-cudf -v --solver=aspcud -c
"-count(solution,APT-Release:=/a=experimental/),-removed,-changed,-new"
/tmp/dump.edsp --dump
Using the --dump option you can also see the cudf translation. To save you the
trouble, I put the EDSP file as an attachment to this mail.
Thanks!
cheers, josch
signature.asc
Description: signature
