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(a)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_fVOjWeF5Pi5PI5E...
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(a)redhat.com>
Business System Analyst, Hosted and Shared Services
PGP: 7B087241
Red Hat Inc.
http://cz.redhat.com