Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
On 11 Jul 2020, at 23:47, Johannes Schauer <josch@debian.org> 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 <kilobyte@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
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
Reply to: