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.
Reply to: