APT's solver is greedy and sometimes has a hard time to recover from paths that
don't work out in the end. We see this with opencv failing to build on !linux-any
because:

(1) dconf-service depends default-dbus-session-bus | dbus-session-bus
(2) default-dbus-session-bus is provided by an Architecture: all package, but
    depends on systemd

APT refuses to install that.

I think it makes sense to amend section 7.1 with the following information:

    Packages on the left hand side of a pipe symbol should either be installable
    or should not exist in the given situation (for example, because it is linux-only
    and the package only exists on non-Linux platform).

This would help reduce hard to solve situations for greedy algorithms.

I guess that's closely related to #590511, but a bit different.

This specific instance of a more general problem is #878878.

In #878878 I'm intending to fix that by:

- changing dbus-user-session from Architecture: all to
  Architecture: linux-any (which means we'll have 20 copies of it instead
  of one, counting non-release architectures, but that's the price we pay
  for retaining best-effort support for non-Linux kernels)

- changing dbus-x11 to add Provides: d-d-s-b [!linux-any]

Is that the resolution that you would recommend?

Thanks,
    smcv

Indeed, that works. Another solution that would _probably_
be ok for APT at least would be to make default-dbus-session
a real package depending on

	systemd | dbus-x11, dbus-user-session | dbus-x11

But that seems weird. (I'd expect apt to pick dbus-x11 in
the first case because systemd does not exist, and then it
would notice that when visiting the second one).

I wish we had linux-all and stuff.

Hi,

Julian Andres Klode wrote:

I agree with this goal.

I'm wondering how a packager would go about fulfilling this recommendation.
Should they audit their dependencies (and dependencies' dependencies, etc) for
installability?  Is there a reliable process they can follow for this?

This is made especially difficult because since policy 4.0.1.0 we are not able
to rely on 'priority: optional' packages being installable any more.

Without such advice, I don't think this makes sense to add as a normative change
to policy (or in other words a policy "should").  An informative note would
still be useful, though.

Thanks,
Jonathan

I think the situation does not happen that often to worry too much about
it. It's mostly a question if something depends on systemd or not, and the
people doing that usually know that. :D
stuff now? The strict installability requirement is much nicer than this one (the
problem is essentially not recursive anymore), and would solve the problem as well.

Well, it's more of an after-the-fact check to determine if a dependency
is right or wrong. If it's informative people might just say "I don't care".

I am not sure if we have tools for checking it, but then we also don't have
a lot of pre-check tool for file conflicts either.

Priority: optional packages are non-conflicting. This is orthogonal to
the situation with dbus-user-session, but introduces a new way in which
a package might be uninstallable for a non-obvious reason (previously,
you could assume that Priority >= optional would never be uninstallable
due to conflicts).

Arch: all packages depending on linux-any packages are another case
of packages being uninstallable for reasons that are at least arguably
legitimate. dbus-user-session is an example of this case (its next upload
will be linux-any, duplicating the package 20 times but ensuring that
it only appears on architectures where it would be installable). This
didn't change in Policy 4.0.1.

It's OK for dbus-user-session to make that change because it's tiny, but
if the Architecture: all package was larger, then duplicating it in the
archive up to 20 times for rarer architectures' benefit would probably
be considered undesirable or unacceptable? For example, if packaging
a large pure-Python GUI that wrapped Valgrind, it would be reasonable
to want it to be Architecture: all to avoid duplicating it, but at the
same time it ought to depend on valgrind, making it uninstallable on
architectures to which valgrind has not yet been ported.

    smcv

I made it Architecture: i386 amd64 to avoid issues more than 10 years
ago, though I'm not exactly sure why...