Bug#878905: debian-policy: Document installability recommendations for dependency alternatives
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.
Bug#878905: debian-policy: Document installability recommendations for dependency alternatives
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
Bug#878905: debian-policy: Document installability recommendations for dependency alternatives
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.
Bug#878905: debian-policy: Document installability recommendations for dependency alternatives
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
Bug#878905: debian-policy: Document installability recommendations for dependency alternatives
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.
Bug#878905: debian-policy: Document installability recommendations for dependency alternatives
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
Bug#878905: debian-policy: Document installability recommendations for dependency alternatives
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
--
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.
