dnf vs yum

Stanislav Ochotnicky sochotnicky at redhat.com
Fri Oct 24 14:56:20 UTC 2014


On Fri 24 Oct 2014 04:27:37 PM CEST Tim Lauridsen wrote:
> On Fri Oct 24 2014 at 4:01:20 PM Stanislav Ochotnicky <
> sochotnicky at redhat.com> wrote:
>
>> On Fri 24 Oct 2014 02:26:37 PM CEST Rahul Sundaram wrote:
>>
>> > Hi
>> >
>> > On Fri, Oct 24, 2014 at 7:58 AM, Vít Ondruch wrote:
>> >
>> >>
>> >> Yes, switch the defaults ASAP. Thanks
>> >>
>> >
>> > FWIW,   there is still considerable work left is switching over to dnf
>> > completely.
>> >
>> > Filtering out some minor details (based on my system),
>> >
>> > Bodhi-client,  fedpkg, python-meh, libreport-python, yum-utils depends on
>> > yum and yum-utils itself is a dependency for fedora-review, lpf and
>> > mock.
>>
>> FWIW fedora-review only requires yum-utils and that's only for
>> repoquery. Based on a quick glance at dnf repoquery module there are a
>> few things missing that we are using with repoquery:
>>  * -C (use cache only)
>>
>
> dnf repoquery can use standard dnf cmd option, so -C/--cacheonly can be
> used.

Ah, right my bad. But really...this will likely not be needed.

>
>>  * --resolve (resolves to packages that provide required symbols)
>>
>
> Not implemented in dnf repoquery yet, please open an RFE against
> dnf-plugins-core, with your usecase and I will look into it.


https://bugzilla.redhat.com/show_bug.cgi?id=1156487

Thought we should really switch to actually use dnf api instead. Things
get complicated for us when we want to support EL6 then...Maybe we should
just drop EPEL6 support.

>> We also run 'yum makecache' so before all actual repoquery commands (that's
>> why we then use cache). This might not be needed with dnf since it
>> usually caches yum metadata and doesn't redownload on every query.
>>
>> Dnf repoquery also behaves differently than yum-utils repoquery. For
>> example:
>> $ repoquery --requires python
>> libc.so.6(GLIBC_2.0)
>> libdl.so.2
>> libm.so.6
>> libpthread.so.0
>> libpython2.7.so.1.0
>> libutil.so.1
>> python-libs(x86-32) = 2.7.5-14.fc20
>> rtld(GNU_HASH)
>> libc.so.6(GLIBC_2.2.5)(64bit)
>> libdl.so.2()(64bit)
>> libm.so.6()(64bit)
>> libpthread.so.0()(64bit)
>> libpython2.7.so.1.0()(64bit)
>> libutil.so.1()(64bit)
>> python-libs(x86-64) = 2.7.5-14.fc20
>> rtld(GNU_HASH)
>>
>> $ dnf repoquery --requires python
>> rtld(GNU_HASH)
>> libm.so.6
>> libpthread.so.0
>> libdl.so.2
>> libutil.so.1
>> libpython2.7.so.1.0
>> libc.so.6(GLIBC_2.0)
>> python-libs(x86-32) = 2.7.5-9.fc20
>> rtld(GNU_HASH)
>> libm.so.6()(64bit)
>> libpthread.so.0()(64bit)
>> libdl.so.2()(64bit)
>> libc.so.6(GLIBC_2.2.5)(64bit)
>> libpython2.7.so.1.0()(64bit)
>> libutil.so.1()(64bit)
>> python-libs(x86-64) = 2.7.5-9.fc20
>> rtld(GNU_HASH)
>> libm.so.6
>> libpthread.so.0
>> libdl.so.2
>> libutil.so.1
>> libpython2.7.so.1.0
>> libc.so.6(GLIBC_2.0)
>> python-libs(x86-32) = 2.7.5-14.fc20
>> rtld(GNU_HASH)
>> libm.so.6()(64bit)
>> libpthread.so.0()(64bit)
>> libdl.so.2()(64bit)
>> libc.so.6(GLIBC_2.2.5)(64bit)
>> libutil.so.1()(64bit)
>> libpython2.7.so.1.0()(64bit)
>> python-libs(x86-64) = 2.7.5-14.fc20
>>
>>
> Can reproduce this repoquery and dnf repoquery show the same for me
>
> https://docs.google.com/spreadsheets/d/1WwlO3Is0psbBuJrIY_fVOjWeF5Pi5PI5Ekiy1raUjbs/edit?usp=sharing

For me 2.7.5-9.fc20 is from fedora/20 repo and python-2.7.5-14.fc20 is
from updates/20. F21 doesn't have updates so maybe that's the reason why
your results look OK?

--
Stanislav Ochotnicky <sochotnicky at redhat.com>
Business System Analyst, Hosted and Shared Services

PGP: 7B087241
Red Hat Inc.                               http://cz.redhat.com


More information about the devel mailing list