[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides
From:       Radek Holy <rholy () redhat ! com>
Date:       2015-06-17 9:08:21
Message-ID: 361063844.17898528.1434532101012.JavaMail.zimbra () redhat ! com
[Download RAW message or body]



----- Original Message -----
> From: "James Antill" <james@fedoraproject.org>
> To: "Development discussions related to Fedora" <devel@lists.fedoraproject.org>
> Sent: Tuesday, June 16, 2015 9:16:27 PM
> Subject: Re: DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides
> 
> On Fri, 2015-06-12 at 15:09 +0200, Kalev Lember wrote:
> > On 06/12/2015 10:28 AM, Radek Holy wrote:
> > > If a package "Requires: foo" and both "bar" and "barbaz" "Provides:
> > > foo", they are handled as being equally suitable. DNF/libsolv is not
> > > going to prefer packages with shorter names.
> > 
> > Yes, very much agreed here. Please don't add the yum shortest name hack
> > to DNF. This and the rest of the depsolving quirks that choose one
> > provider over the other depending on what else happens to be installed,
> > have made my life quite hard over the years :)
> 
> You would rather have it undocumented and/or random which of the
> providers it chooses ... and this will make your life easier? Ok.

Not random. And the documentation is not needed. All packages providing the given \
provide are handled as being equally suitable. And that's how it should work. The \
actual choice is an implementation detail and packages should not depend on it. They \
don't need to depend on it since they should work the same with all the packages that \
provide the same requirement/interface. Otherwise the virtual provides would have no \
sense.

> > With the yum system, yum would pretty much always just pick the shortest
> > name. It _happened_ to be PackageKit-yum, but that was totally an
> > accident. And it made it impossible to change the default without
> > renaming the packages - so in a new release that was supposed to use
> > hawkey, we'd have very little options besides renaming PackageKit-hawkey
> > to PackageKit-h for example to make sure it wins over -yum.
> 
> That's not true, the obvious change would be to have versions on the
> provide and have the hawkey (default) one be higher. This comes before
> shortest name (which is the last thing yum uses):
> 
> http://yum.baseurl.org/wiki/CompareProviders

Yes, that's the hack which is used by mariadb and community-mysql. From my point of \
view, such provide is a plain lie. If both packages implement the same version of \
MySQL interface, the provide should have the same version.

Despite the fact that this "solution" is not very systematic since it requires all \
the packages to keep this inequality between the provides forever.

> ...although it would also just work if yum wasn't installed by default,
> given the yum backend would bring in a bunch more deps.
> 
> Although, to be fair, this case is a bit more complicated as you'd want
> to migrate everyone on the -yum backend to the -hawkey backend ... so
> you can't just rely on new install defaults to accomplish that, random
> or documented.
> 
> > What I feel would be a good solution to the problem above would be to
> > have a way to specify the default. I believe this problem is already
> > solved in apt-get with a very nice syntax: the OR syntax:
> > 
> > Requires: PackageKit-hawkey | PackageKit-backend
> 
> Look at the weak deps. and rich deps. work, which might help here (but
> again, not really in the case you chose).
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


[prev in list] [next in list] [prev in thread] [next in thread]