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 via email to