XPost: linux.debian.bugs.dist

Package: debian-policy
Severity: normal

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.


-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (900, 'unstable'), (900, 'testing'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debian-policy depends on:
ii libjs-sphinxdoc 1.6.4-2

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn doc-base <none>

--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

On Tue, 17 Oct 2017 at 18:12:29 +0200, Julian Andres Klode wrote:

(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.

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

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).

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

On Tue, Oct 17, 2017 at 06:03:43PM +0100, Simon McVittie wrote:

On Tue, 17 Oct 2017 at 18:12:29 +0200, Julian Andres Klode wrote:

(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.

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

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).

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?

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.

--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

Hi,

Julian Andres Klode wrote:

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:

I agree with this goal.

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'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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

On Wed, 18 Oct 2017 at 11:54:49 +0200, Julian Andres Klode wrote:

On Tue, Oct 17, 2017 at 11:02:21AM -0700, Jonathan Nieder wrote:

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.

Oh did we drop that? Why? So I can build Arch: all packages depending on linux-any
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.

The change in Policy 4.0.1 was to drop the requirement that
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

On Tue, Oct 17, 2017 at 11:02:21AM -0700, Jonathan Nieder wrote:

Hi,

Julian Andres Klode wrote:

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:

I agree with this goal.

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'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?

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

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.

Oh did we drop that? Why? So I can build Arch: all packages depending on linux-any
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.

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.

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.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

On Wed, Oct 18, 2017 at 11:47:56AM +0100, Simon McVittie wrote:

On Wed, 18 Oct 2017 at 11:54:49 +0200, Julian Andres Klode wrote:

On Tue, Oct 17, 2017 at 11:02:21AM -0700, Jonathan Nieder wrote:

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.

Oh did we drop that? Why? So I can build Arch: all packages depending on linux-any
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.

The change in Policy 4.0.1 was to drop the requirement that
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.

The prime example I have is ndisgtk which is a pure python app, but
I made it Architecture: i386 amd64 to avoid issues more than 10 years
ago, though I'm not exactly sure why...

--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)