Bug#1114810: apt-get build-dep wrongly pretends unmet dependencies

David Kalnischkies <[email protected]> Thu, 11 Sep 2025 11:25:11 +0200
Newsgroups	gmane.linux.debian.apt.devel
Message-ID	<lfqqhekhx2hypmczogtpio633ywk6zamugzwovt4fyhnh6glro__44076.5330380359$1757584047$gmane$org@qzgiejee5kaj>
Am Wed, Sep 10, 2025 at 09:01:15AM +0200, schrieb Fab Stz:
> In a clean schroot environment with unstable, I try to run
> 
> apt-get build-dep .
> 
> This leads to:
> 
> The following packages have unmet dependencies:
>  builddeps:. : Depends: mono-devel (>= 6.14.1+ds-6) but it is not installable or
>                         cli-common-dev but it is not installable
>  keepass2 : Depends: mono-runtime (>= 3.0~) but it is not installable
> E: Unable to correct problems, you have held broken packages.
> 
> 
> Please note that building the package works:
> - locally (with sbuild), I also tried locally with sbuild+aspcud resolver, and
> it built fine as well.
> - on Debusine https://debusine.debian.net/debian/developers/work-
> request/167461/
> - and in the archive
> https://buildd.debian.org/status/fetch.php?pkg=keepass2-plugin-
> keepassrpc&arch=all&ver=2.0.2+dfsg2-3&stamp=1757401952&raw=0
> 
> See also https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/485

APT isn't entirely wrong here.

Seeing the build-depends on keepass2 first the resolver decides to pick
libmono-corlib4.5-cil – the real package – for installation, which does
not work as it later wants to install mono-libraries – a virtual
provider – that breaks earlier versions of the real package. Or as
solver3 explains if you happen to ask:

$ LANG=C apt install libmono-corlib4.5-cil -s -o Dir::state::status=/dev/null
Error: The following information from --solver 3.0 may provide additional context:
   Unable to satisfy dependencies. Reached two conflicting decisions:
   1. mono-runtime:amd64 is selected for install because:
      1. libmono-corlib4.5-cil:amd64=6.14.1+ds-2 is selected for install
      2. libmono-corlib4.5-cil:amd64=6.14.1+ds-2 Depends mono-runtime (>= 2.10.1)
   2. mono-runtime:amd64 is available in versions 6.14.1+ds2-1, 6.12.0.199+dfsg-6
      but none of the choices are installable:
      - mono-runtime:amd64=6.14.1+ds2-1 Depends mono-libraries
        but none of the choices are installable:
        - mono-libraries:amd64 is not selected for install because:
          1. libmono-corlib4.5-cil:amd64=6.14.1+ds-2 is selected for install as above
          2. mono-libraries:amd64 Breaks libmono-corlib4.5-cil (< 6.14.1+ds-3)
             [selected libmono-corlib4.5-cil:amd64=6.14.1+ds-2]
      - mono-runtime:amd64=6.12.0.199+dfsg-6 is not selected for install


Now, in this install request I explicitly asked for it, so the
resolver can't decide against that. The output of
$ apt build-dep . -so Debug::pkgProblemResolver=1 -o Debug::pkgDepCache::Marker=1
      MarkInstall libmono-corlib4.5-cil:amd64 < none -> 6.14.1+ds-2 @un uN Ib > FU=0
        MarkInstall mono-runtime:amd64 < none -> 6.14.1+ds2-1 @un uN Ib > FU=0
          Ignore MarkKeep of libmono-corlib4.5-cil:amd64 < none -> 6.14.1+ds-2 @un puN > as its mode (Install) is protected
          mono-runtime:amd64 Depends on mono-libraries:amd64 < none | 6.14.1+ds2-1 @un uH > can't be satisfied! (dep)
        libmono-corlib4.5-cil:amd64 Depends on mono-runtime:amd64 < none @un H > (>= 2.10.1) can't be satisfied! (dep)
      MarkInstall mono-libraries:amd64 < none -> 6.14.1+ds2-1 @un uN Ib > FU=0

suggests it figures that one out, but draws too many conclusions from
that failure as it seems to record mono-runtime:amd64 as uninstallable
not only in this path, but globally.

sbuild uses apt (and its resolver), too, but not the build-dep command.
It rewrites the build-dependencies to remove or-groups and such,
perhaps it reorders, too, or does something else to get lucky.
(perhaps even something as simple as timing as its version mismatches at
 its core that tend to fix itself with time while new ones appear)

You can also observe this (original) order to fail:
$ LANG=C apt satisfy 'keepass2, mono-devel' -s -o Dir::state::status=/dev/null
while it works with reordering:
$ LANG=C apt satisfy 'mono-devel, keepass2' -s -o Dir::state::status=/dev/null


In any case, while this might be a bug in apt, its one you will have to
live with for the foreseeable future as we do not patch stable.
This setup looks like an even worse one in mono packages, but I don't
know that ecosystem at all, so I hope its temporary…

If the plan is to replace the individual library packages with the
mono-libraries bundle I would strongly advice to introduce transitional
packages instead of trying to make it work without them as this is only
the very tiny tip of the iceberg of problems you will run into.


Best regards

David Kalnischkies
signature.asc (application/pgp-signature, 833 B)