On Wed, 2011-11-02 at 08:31 +0100, Tomas Mraz wrote:
On Wed, 2011-11-02 at 09:31 +0530, Rahul Sundaram wrote:
> On 11/02/2011 07:54 AM, Kevin Kofler wrote:
> > Stephen Gallagher wrote:
> >> * #683 - Zif as default PackageKit backend for desktop users -
> >> http://fedoraproject.org/wiki/Features/ZifByDefaultForDesktop
> >> (sgallagh, 17:03:32)
> >> * AGREED: ZifByDefaultForDesktop is refused as a Feature for Fedora 17
> >> (sgallagh, 17:07:32)
> > IMHO refusing this was a bad idea when the more general rule was originally
> > decided and is still a bad idea now. You're essentially blackmailing zif
> > upstream: "Either you fully support command-line users or you will never
> > the default in Fedora's PackageKit."
> I don't think this is the argument. Having potentially different
> behaviour between command line dep resolver and gui dep resolver is very
> problematic and this is a important concern.
Exactly, Kevin is skewing the reason of the decision here. The reject is
not based on the whole backend as is but purely on the depsolver
algorithm. As soon as yum and zif share the depsolver (not just the
transaction depsolver in rpm, but the depsolver solving which packages
to put into the transaction), then zif would be allowed as the default
backend for PackageKit. There were some proposals/ideas by the rpm
developers to implement this depsolver in librpm although I do not know
whether there was any progress in this recently.
To further attempt to clarify, the problem here is that Zif and Yum
currently have different algorithms for determining what package will
satisfy a dependency (if there is more than one can possibly accomplish
it). For example, let's say that a project dies off and two new forks
spring up to continue development (divergently). Both packages can
appear in Fedora and both will have "Obsoletes: Oldpackage". Currently,
yum and zif may make different decisions about which of the two new
versions to pull in automatically.
Our only resistance to Zif in Fedora 17 is due to this conflict. There
are three options here:
1) Zif switches to using yum's dependency resolver
2) Yum switches to using Zif's dependency resolver
3) Both projects agree on an algorithm and share a library to make these
I personally prefer option 3) as it will be the most maintainable going
forward. Putting this into librpm is probably the right place IMHO.