I am sorry I did not fully follow the discussions earlier.
I only recall it was supposed to exist some compatibility layer at some point.
But I keep all the time needing to
$ sudo rm -f /var/lib/rpm/__db*
because I forget and use yum instead of dnf in rawhide.
I am not really needing anything special, just install a package, or run "dnf update" to update rawhide.
Thanks, Paulo
I am sorry I did not fully follow the discussions earlier. I only recall it was supposed to exist some compatibility layer at some point.
But I keep all the time needing to
$ sudo rm -f /var/lib/rpm/__db*
there is no need to do so
because I forget and use yum instead of dnf in rawhide.
I am not really needing anything special, just install a package, or run "dnf update" to update rawhide
but why do you think you need to touch anything below /var/lib/rpm/? that's the rpm database you should never touch without damned good reasons like follow dist-upgrade instructions
you can happily use "yum" and "dnf" on the same setup all the time and the warnings "rpm database modified" or similar are harmless, you may even trigger them by touch the rpmdb by hand
2014-10-04 11:08 GMT-03:00 Reindl Harald h.reindl@thelounge.net:
First think of me of as just an slightly above average user :)
I am sorry I did not fully follow the discussions earlier. I only recall it was supposed to exist some compatibility layer at some point.
But I keep all the time needing to
$ sudo rm -f /var/lib/rpm/__db*
there is no need to do so
I switched to using dnf because yum stopped working at some point. I think it was something related to a libdb-5 update when only dnf would work.
because I forget and use yum instead of dnf in rawhide.
I am not really needing anything special, just install a package, or run "dnf update" to update rawhide
but why do you think you need to touch anything below /var/lib/rpm/? that's the rpm database you should never touch without damned good reasons like follow dist-upgrade instructions
I learned to do that (rm -f /var/lib/rpm/__db*) long long ago, as the standard way to recover from "minor" rpm database corruption. But I survived extreme cases where not even "rpm --rebuilddb" would work. As long as the Packages database is not (completely) corrupted, it should be possible to recover...
you can happily use "yum" and "dnf" on the same setup all the time and the warnings "rpm database modified" or similar are harmless, you may even trigger them by touch the rpmdb by hand
It does not work for me... I sent the email because, I again, forgot and run $ sudo yum update
and gone to another terminal, a bit later I learned that yum thought all updates would be duplicates, so I did
$ sudo rm -f /var/lib/rpm/__db* $ sudo dn update
sent the email, and now, update to latest rawhide has already finished...
Thanks, Paulo
Am 04.10.2014 um 16:49
2014-10-04 11:08 GMT-03:00 Reindl Harald h.reindl@thelounge.net: First think of me of as just an slightly above average user :)
I am sorry I did not fully follow the discussions earlier. I only recall it was supposed to exist some compatibility layer at some point.
But I keep all the time needing to
$ sudo rm -f /var/lib/rpm/__db*
there is no need to do so
I switched to using dnf because yum stopped working at some point. I think it was something related to a libdb-5 update when only dnf would work.
but than you have a different problem not really related to the subject
because I forget and use yum instead of dnf in rawhide.
I am not really needing anything special, just install a package, or run "dnf update" to update rawhide
but why do you think you need to touch anything below /var/lib/rpm/? that's the rpm database you should never touch without damned good reasons like follow dist-upgrade instructions
I learned to do that (rm -f /var/lib/rpm/__db*) long long ago, as the standard way to recover from "minor" rpm database corruption. But I survived extreme cases where not even "rpm --rebuilddb" would work. As long as the Packages database is not (completely) corrupted, it should be possible to recover...
as said: than you have a much deeper problem
you can happily use "yum" and "dnf" on the same setup all the time and the warnings "rpm database modified" or similar are harmless, you may even trigger them by touch the rpmdb by hand
It does not work for me... I sent the email because, I again, forgot and run $ sudo yum update
and gone to another terminal, a bit later I learned that yum thought all updates would be duplicates, so I did
$ sudo rm -f /var/lib/rpm/__db* $ sudo dn update
sent the email, and now, update to latest rawhide has already finished...
again: something is broken on your system and you should fix that with the help of "package-cleanup" and options like dupes, prohans and so on
what you see is not normal and don't match the subject
both, yum and dnf are *frontends* for the rpm database which is a complete different layer hence you can use plain "rpm -Uvh", yum and dnf as you like if it don't come to dependencies where dnf/yum are still frontends for rpm and just do the work you would normally need to do by hand
On Sat, Oct 04, 2014 at 11:02:23AM -0300, Paulo César Pereira de Andrade wrote:
I only recall it was supposed to exist some compatibility layer at some point. But I keep all the time needing to $ sudo rm -f /var/lib/rpm/__db* because I forget and use yum instead of dnf in rawhide.
I'm not sure why you would need to do that because of running yum, but, one thing you can do is remove the yum package and install dnf-yum instead, which provides a /usr/bin/yum compatibility wrapper.
2014-10-04 13:32 GMT-03:00 Matthew Miller mattdm@fedoraproject.org:
On Sat, Oct 04, 2014 at 11:02:23AM -0300, Paulo César Pereira de Andrade wrote:
I only recall it was supposed to exist some compatibility layer at some point. But I keep all the time needing to $ sudo rm -f /var/lib/rpm/__db* because I forget and use yum instead of dnf in rawhide.
I'm not sure why you would need to do that because of running yum, but, one thing you can do is remove the yum package and install dnf-yum instead, which provides a /usr/bin/yum compatibility wrapper.
Sorry for late reply. I was aware of dnf-yum, that I assume will magically correct my problem. I did not remove "plain" yum so far on purpose, because I was expecting it to be automatically replaced, or kept working, but only now I sent a note about the problems I noticed :)
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader
Thanks, Paulo
Hi
On Sat, Oct 4, 2014 at 5:03 PM, Paulo César Pereira de Andrade
I did not remove "plain" yum so far on purpose, because I was expecting it to be automatically replaced, or kept working, but only now I sent a note about the problems I noticed :)
Would you filing a bug report against yum or dnf? I use both interchangeability (for testing dnf) and I haven't run into this issue.
https://fedoraproject.org/wiki/How_to_file_a_bug_report
http://bugz.fedoraproject.org/dnf
Rahul
2014-10-04 18:23 GMT-03:00 Rahul Sundaram metherid@gmail.com:
Hi
On Sat, Oct 4, 2014 at 5:03 PM, Paulo César Pereira de Andrade
I did not remove "plain" yum so far on purpose, because I was expecting it to be automatically replaced, or kept working, but only now I sent a note about the problems I noticed :)
Would you filing a bug report against yum or dnf? I use both interchangeability (for testing dnf) and I haven't run into this issue.
I checked that I was talking from experience as 1 or more weeks ago. For a single package install indeed, dnf and yum are now working.
I figured I have a lot of duplicates left from some earlier update, for example:
$ rpm -q xz-libs xz-libs-5.1.2-13alpha.fc22.x86_64 xz-libs-5.1.2-15alpha.fc22.x86_64 xz-libs-5.1.2-15alpha.fc22.i686
So, I should work on some script to rpm -e --justdb the older ones. The initial report in this thread was due to another kind of error, e.g. "yum update" says among thousands of other lines:
xz-libs-5.1.2-15alpha.fc22.i686 is a duplicate with xz-libs-5.1.2-13alpha.fc22.x86_64
but yum output could be good as input for some script attempting to fix my rawhide, example:
4:texlive-zxjafbfont-svn28539.0-2.fc22.noarch is a duplicate with 4:texlive-zxjafbfont-svn28539.0-1.fc22.noarch 4:texlive-zxjafont-svn30105.0.2-2.fc22.noarch is a duplicate with 4:texlive-zxjafont-svn30105.0.2-1.fc22.noarch 4:texlive-zxjatype-svn28541.0.6-2.fc22.noarch is a duplicate with 4:texlive-zxjatype-svn28541.0.6-1.fc22.noarch
Just to have an idea:
$ sudo yum update >& /tmp/yum $ wc -l /tmp/yum 3589 /tmp/yum $ sudo dnf update >& /tmp/dnf $ wc -l /tmp/dnf 2 /tmp/dnf $ cat /tmp/dnf Dependencies resolved. Nothing to do.
If I manage to make a clean bug report I will submit it. Rawhide changes too fast that when one takes some time, and fills a bug report, it may have been already fixed :)
Rahul
Thanks, Paulo
I checked that I was talking from experience as 1 or more weeks ago. For a single package install indeed, dnf and yum are now working.
I figured I have a lot of duplicates left from some earlier update, for example:
$ rpm -q xz-libs xz-libs-5.1.2-13alpha.fc22.x86_64 xz-libs-5.1.2-15alpha.fc22.x86_64 xz-libs-5.1.2-15alpha.fc22.i686
So, I should work on some script to rpm -e --justdb the older ones
as i already said - just stop to mangle around in your rpmdb and use the tools available for years
* yum install yum-utils * package-cleanup --help * package-cleanup --dupes * package-cleanup --cleandupes
the subject is stil wrong as well as the mailing list you have a *local* problem
W dniu 04.10.2014 o 18:32, Matthew Miller pisze:
I'm not sure why you would need to do that because of running yum, but, one thing you can do is remove the yum package and install dnf-yum instead, which provides a /usr/bin/yum compatibility wrapper.
Too bad that it does not also say that it provides yum ;(
09:52 root@pinkiepie-rawhide:mnt$ dnf install dnf-yum mock Error: package mock-1.1.41-3.fc22.noarch requires yum >= 2.4, but none of the providers can be installed
Hi
On Mon, Oct 6, 2014 at 3:52 AM, Marcin Juszkiewicz wrote:
Too bad that it does not also say that it provides yum ;(
09:52 root@pinkiepie-rawhide:mnt$ dnf install dnf-yum mock Error: package mock-1.1.41-3.fc22.noarch requires yum >= 2.4, but none of the providers can be installed
Because it doesn't provide yum. It only provides a command line api. Tools that depend on the yum API including mock won't work with dnf-yum. They actually need to be ported over just like yumex-dnf has.
Rahul
----- Original Message -----
From: "Rahul Sundaram" metherid@gmail.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Monday, October 6, 2014 10:00:54 AM Subject: Re: dnf vs yum
Hi
On Mon, Oct 6, 2014 at 3:52 AM, Marcin Juszkiewicz wrote:
Too bad that it does not also say that it provides yum ;(
09:52 root@pinkiepie-rawhide:mnt$ dnf install dnf-yum mock Error: package mock-1.1.41-3.fc22.noarch requires yum >= 2.4, but none of the providers can be installed
Because it doesn't provide yum. It only provides a command line api. Tools that depend on the yum API including mock won't work with dnf-yum. They actually need to be ported over just like yumex-dnf has.
Mock-1.2 no longer depends on yum API and has been ported to use DNF. So if you use the new version and set config_opts['package_manager']='dnf' and also install dnf-plugins-core, you should be able to use it without any problems. But the dnf-yum (/usr/bin/yum being symlink to dnf) scenario is not supported yet, you have to explicitly tell it to use dnf, otherwise it won't work. dnf and yum don't always behave the same and mock has to treat them a bit differently. But the package itself still needs to depend on yum, because even if dnf-yum was supported, it doesn't pull in dnf-plugins-core package which contains builddep command.
Michael Simacek
Rahul
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Hi
On Fri, Oct 24, 2014 at 3:51 AM, Michael Simacek wrote:
Mock-1.2 no longer depends on yum API and has been ported to use DNF. So if you use the new version and set config_opts['package_manager']='dnf' and also install dnf-plugins-core, you should be able to use it without any problems. But the dnf-yum (/usr/bin/yum being symlink to dnf) scenario is not supported yet, you have to explicitly tell it to use dnf, otherwise it won't work. dnf and yum don't always behave the same and mock has to treat them a bit differently. But the package itself still needs to depend on yum, because even if dnf-yum was supported, it doesn't pull in dnf-plugins-core package which contains builddep command.
I don't quite understand that explanation. For rawhide, why doesn't mock drop the dependency on yum and add a dependency on dnf *and* dnf-plugins-core?
Rahul
On Fri Oct 24 2014 at 12:46:41 PM Rahul Sundaram metherid@gmail.com wrote:
Hi
On Fri, Oct 24, 2014 at 3:51 AM, Michael Simacek wrote:
Mock-1.2 no longer depends on yum API and has been ported to use DNF. So if you use the new version and set config_opts['package_manager']='dnf' and also install dnf-plugins-core, you should be able to use it without any problems. But the dnf-yum (/usr/bin/yum being symlink to dnf) scenario is not supported yet, you have to explicitly tell it to use dnf, otherwise it won't work. dnf and yum don't always behave the same and mock has to treat them a bit differently. But the package itself still needs to depend on yum, because even if dnf-yum was supported, it doesn't pull in dnf-plugins-core package which contains builddep command.
I don't quite understand that explanation. For rawhide, why doesn't mock drop the dependency on yum and add a dependency on dnf *and* dnf-plugins-core?
Mock still defaults to yum, but supports dnf also using config_opts['package_manager']='dnf'
So it makes sense to have a hard requirement on yum
Tim
On Fri Oct 24 2014 at 1:23:27 PM Rahul Sundaram metherid@gmail.com wrote:
Hi
On Fri, Oct 24, 2014 at 6:51 AM, Tim Lauridsen wrote:
Mock still defaults to yum, but supports dnf also using config_opts['package_manager']='dnf'
So it makes sense to have a hard requirement on yum
Well the question is, why doesn't it default to dnf in Rawhide?
Proberly because dnf support is very new, so it will need some more real time use before the default is switched
Tim
Rawhide is far from "realtime use" in my book as that means public use not just developer/tester types
Corey W Sheldon Freelance IT Consultant, Multi-Discipline Tutor 310.909.7672 www.facebook.com/1stclassmobileshine
On Fri, Oct 24, 2014 at 7:33 AM, Rahul Sundaram metherid@gmail.com wrote:
Hi
On Fri, Oct 24, 2014 at 7:27 AM, Tim Lauridsen wrote:
Proberly because dnf support is very new, so it will need some more real time use
That would be a good reason to switch the default in Rawhide at this stage.
Rahul
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Am 24.10.2014 um 13:38 schrieb Corey Sheldon:
Rawhide is far from "realtime use" in my book as that means public use not just developer/tester types
and how do you ever reach "public use" if it keeps disabled for devel/testing?
On Fri, Oct 24, 2014 at 7:33 AM, Rahul Sundaram <metherid@gmail.com
On Fri, Oct 24, 2014 at 7:27 AM, Tim Lauridsen wrote: Proberly because dnf support is very new, so it will need some more real time use That would be a good reason to switch the default in Rawhide at this stage.
its in the repos and in the test release notes last i saw so use as you feel and test it out and last i checked while it is the cornerstone feature not likely a blocker as yum is still working and IT is afterall a fork of yum
Corey W Sheldon Freelance IT Consultant, Multi-Discipline Tutor 310.909.7672 www.facebook.com/1stclassmobileshine
On Fri, Oct 24, 2014 at 7:42 AM, Reindl Harald h.reindl@thelounge.net wrote:
Am 24.10.2014 um 13:38 schrieb Corey Sheldon:
Rawhide is far from "realtime use" in my book as that means public use not just developer/tester types
and how do you ever reach "public use" if it keeps disabled for devel/testing?
On Fri, Oct 24, 2014 at 7:33 AM, Rahul Sundaram <metherid@gmail.com
On Fri, Oct 24, 2014 at 7:27 AM, Tim Lauridsen wrote: Proberly because dnf support is very new, so it will need some more real time use That would be a good reason to switch the default in Rawhide at this stage.
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Am 24.10.2014 um 13:45 schrieb Corey Sheldon:
its in the repos and in the test release notes last i saw so use as you feel and test it out and last i checked while it is the cornerstone feature not likely a blocker as yum is still working and IT is afterall a fork of yum
first: stop top posting and place your signature in the middle of a thread
second: your comments after Rahul's "That would be a good reason" don't make any sense, he is right that new things which are planned to replace in the final GA release should be enabled in development
"it's in the repos so use as you feel" is with all respect nonsense, *you missed* the *koji* context - i have no use for koji here, but the Fedora infrastrucure and upstream development has
On Fri, Oct 24, 2014 at 7:42 AM, Reindl Harald:
Am 24.10.2014 um 13:38 schrieb Corey Sheldon: Rawhide is far from "realtime use" in my book as that means public use not just developer/tester types and how do you ever reach "public use" if it keeps disabled for devel/testing? On Fri, Oct 24, 2014 at 7:33 AM, Rahul Sundaram <metherid@gmail.com <mailto:metherid@gmail.com> On Fri, Oct 24, 2014 at 7:27 AM, Tim Lauridsen wrote: Proberly because dnf support is very new, so it will need some more real time use That would be a good reason to switch the default in Rawhide at this stage.
On Fri, Oct 24, 2014 at 07:33:06AM -0400, Rahul Sundaram wrote:
Hi On Fri, Oct 24, 2014 at 7:27 AM, Tim Lauridsen wrote:
Proberly because dnf support is very new, so it will need some more real time use
That would be a good reason to switch the default in Rawhide at this stage.
+1 there, after all DNF is planned to be made the default in F22 according to: http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
Pierre
Dne 24.10.2014 v 13:43 Pierre-Yves Chibon napsal(a):
On Fri, Oct 24, 2014 at 07:33:06AM -0400, Rahul Sundaram wrote:
Hi On Fri, Oct 24, 2014 at 7:27 AM, Tim Lauridsen wrote:
Proberly because dnf support is very new, so it will need some more real time use
That would be a good reason to switch the default in Rawhide at this stage.
+1 there, after all DNF is planned to be made the default in F22 according to: http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
Pierre
Yes, switch the defaults ASAP. Thanks
Vít
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. I am only aware of the recent mock and yumex efforts. I have no idea if the rest of the projects are being prodded to switch over and whether this is all being tracked somewhere. If not, it should be.
Rahul
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) * --resolve (resolves to packages that provide required symbols)
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
No idea why it's this way though.
-- Stanislav Ochotnicky sochotnicky@redhat.com Business System Analyst, Hosted and Shared Services
PGP: 7B087241 Red Hat Inc. http://cz.redhat.com
On Fri Oct 24 2014 at 4:01:20 PM Stanislav Ochotnicky < sochotnicky@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.
- --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.
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_fVOjWeF5Pi5PI5Ekiy...
Tim
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@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_fVOjWeF5Pi5PI5Ekiy...
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@redhat.com Business System Analyst, Hosted and Shared Services
PGP: 7B087241 Red Hat Inc. http://cz.redhat.com
On Fri, Oct 24, 2014 at 04:56:20PM +0200, Stanislav Ochotnicky wrote:
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.
"Drop" as in "use yum for that, but dnf for the new versions"? That sounds reasonable.
On Fri 24 Oct 2014 05:35:00 PM CEST Matthew Miller wrote:
On Fri, Oct 24, 2014 at 04:56:20PM +0200, Stanislav Ochotnicky wrote:
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.
"Drop" as in "use yum for that, but dnf for the new versions"? That sounds reasonable.
Well reality is f-r is mostly for checking *current* Fedora guidelines that in some cases apply only to rawhide. If someone is running f-r on a system from 4 years ago to verify current packaging guidelines I'd question their knowledge of the guidelines :-)
It's not impossible to do...I just wonder about cost/value proposition of keeping the support and spending even more time on it.
-- Stanislav Ochotnicky sochotnicky@redhat.com Business System Analyst, Hosted and Shared Services
PGP: 7B087241 Red Hat Inc. http://cz.redhat.com
"Drop" as in "use yum for that, but dnf for the new versions"? That sounds reasonable.
Well reality is f-r is mostly for checking *current* Fedora guidelines that in some cases apply only to rawhide. If someone is running f-r on a system from 4 years ago to verify current packaging guidelines I'd question their knowledge of the guidelines :-)
It's not impossible to do...I just wonder about cost/value proposition of keeping the support and spending even more time on it.
f-r should proberly be working in current Fedora releases, F20, F21 & Rawhide, some kind of compability wrapper could be need, some f-r check code is the same and the wrapper can support yum-utils and dnf 5.x (F20) and 6.x API (F21 & F22) (The cache setup is different)
Tim
On Fri, Oct 24, 2014 at 10:00 AM, Stanislav Ochotnicky wrote:
On Fri 24 Oct 2014 02:26:37 PM CEST Rahul Sundaram wrote:
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
Right. I have filed the following RFE's
Fedora-review https://bugzilla.redhat.com/show_bug.cgi?id=1156479
Python-meh
https://bugzilla.redhat.com/show_bug.cgi?id=1156483
libreport-python
https://bugzilla.redhat.com/show_bug.cgi?id=1156485
Bodhi-client
https://bugzilla.redhat.com/show_bug.cgi?id=1156481
lpf
https://bugzilla.rpmfusion.org/show_bug.cgi?id=3391
Tracker bug
https://bugzilla.redhat.com/show_bug.cgi?id=1156491
Hope that helps
Rahul
Hi
Of course, dnf repoquery for packages that depend on yum/yum-utils yielded quite a few more packages. So I have filed RFE's against all of them and added them to the tracker and fixed the wiki references etc just to complete this process
https://bugzilla.redhat.com/showdependencytree.cgi?id=1156491
https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
It is possible, even likely that some packages just assumed yum/yum-utils would always be there and didn't add an explicitly dependency. Since some base tools including mock still depend on yum by default in rawhide, we wouldn't know about those hidden issues till those are ported over/dependency on yum is dropped.
Rahul
On 10/24/2014 01:33 PM, Rahul Sundaram wrote:
That would be a good reason to switch the default in Rawhide at this stage.
No. This is the *first* release with explicit DNF support. Until now it was tested only by those who run mock directly from git checkout (that is maybe 3-5 people). Now it is distributed as rpm (in rawhide, and for older releases in Copr) and is tested by those willing to modify site-defaults.cfg. And hopefully by those built application, which use mock.
I will swap the defaults, once I will be confident that the new feature works flawlessly. But that is not now. I really do not want to break Koji.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 24 Oct 2014 14:59:14 +0200 Miroslav Suchý msuchy@redhat.com wrote:
On 10/24/2014 01:33 PM, Rahul Sundaram wrote:
That would be a good reason to switch the default in Rawhide at this stage.
No. This is the *first* release with explicit DNF support. Until now it was tested only by those who run mock directly from git checkout (that is maybe 3-5 people). Now it is distributed as rpm (in rawhide, and for older releases in Copr) and is tested by those willing to modify site-defaults.cfg. And hopefully by those built application, which use mock.
I will swap the defaults, once I will be confident that the new feature works flawlessly. But that is not now. I really do not want to break Koji.
we will need to have extensive testing of building epel5 epel6 epel7 f20 f21 f22 builds using dnf to populate the buildroots before we can think of switching mock used in koji to using dnf for resolving. we may be forced to stay with yum for some time yet if things do not work with the older epel releases, or we may need to have builders in different channels for doing different tasks. I really appreciate not breaking koji. another good reason to not switch the default just yet is that it may yield different results to what you get in koji.
Dennis