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@xxxxxxxxxx> 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@xxxxxxxxxx> Business System Analyst, Hosted and Shared Services PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
