On Wed, Jul 08, 2020 at 03:44:21PM +0200, Ansgar wrote:
> On Wed, 2020-07-08 at 11:04 +0200, Johannes Schauer wrote:
> > 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).
>
> libsystemd0 doesn't seem special though? It's `Priority: optional` and
> doesn't have much else; I guess trying to uninstall libsystemd0 breaks
> something else?
>
> I'm not really motivated to debug problems caused by elogind though.
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.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀ -- <willmore> on #linux-sunxi
⠈⠳⣄⠀⠀⠀⠀
