Hi, On Fri, 3 Jul 2020 15:36:56 +0100 Mark Hindley <m...@hindley.org.uk> wrote: > On Tue, Jun 30, 2020 at 07:43:52PM +0200, Ansgar wrote: > > On Tue, 2020-06-30 at 17:45 +0100, Mark Hindley wrote: > > > I am struggling to understand how libelogind0 came to be installed in the > > > build > > > in the first place. Can you help me understand that? > > > > No idea; apt's resolver is sometimes creative. Other examples include > > [1], [2], [3]. > > > > [1]: > > https://buildd.debian.org/status/logs.php?pkg=hplip&ver=3.20.6%2Bdfsg0-1&arch=amd64 > > [2]: > > https://buildd.debian.org/status/logs.php?pkg=gnome-applets&ver=3.37.2-1&arch=amd64 > > [3]: > > https://buildd.debian.org/status/logs.php?pkg=kopete&ver=4%3A20.04.1-1&arch=amd64 > > The common feature in all of these experimental buildd failures is that > apt-cudf > fails to find the correct solution leaving a libsystemd-dev <=> libelogind0 > conflict.
What is happening here is, that aspcud chooses libelogind0 for installation and then apt decides that it refuses to install it because it doesn't want to remove libsystemd0 in favor of libelogind0 and by that replace an important package (apt would require the "yes, do as I say!" thing for that to work). But instead of re-assigning this to apt for ignoring part of the installation request by apt-cudf, maybe we can solve this differently. Ansgar, can you tell me which preferences you pass for experimental installations on the buildds? I'm looking for the APT::Solver::aspcud::Preferences setting that is used by sbuild. It might be possible to tweak this setting such that aspcud can find a solution that does not changing Essential:yes packages. Thanks! cheers, josch
signature.asc
Description: signature
