On 11 Jul 2020, at 23:47, Johannes Schauer <[email protected]> wrote: > > 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 <[email protected]> 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
Is this not the bug I fixed a while ago and you committed upstream recently[1]? There hasn't been a dose3 upload to Debian yet with that fixed. Jess [1] https://scm.gforge.inria.fr/anonscm/gitweb?p=dose/dose.git;a=commitdiff;h=226e7eb544bd02b128c19be5e79a9b236439159f
