I just spoke with two members of DNF team about default usage of DNF in mock. I would like to share outcomes of this meeting.
First I would like to state that you can already optionally use DNF in your mock by setting: config_opts['package_manager'] = 'dnf' in your /etc/mock/site-defaults.cfg It is present in mock for half a year and all known problems have been resolved for some time. You can even set this option per chroot target. E.g. put this line only in /etc/mock/fedora-rawhide-x86_64.cfg and then only rawhide-x86_64 builds will use dnf while everything else will use yum.
DNF should be default packager manager in Fedora 22, so I started thinking how it affects mock.
I have a notion, that after branching of Fedora 22 I will change /etc/mock/fedora-rawhide-*.cfg to use DNF by default. I.e. everything build for Fedora 23 would use DNF for building.
At the outset I thought that we use yum for older targets (epel-7, fedora-22..) indefinitely. Or to be precise until those targets will be EOLed. But that would imply that yum have to be present in Fedora until Fedora 40 [1]. This is very unlikely to happen. More realistic expectation is that yum will disappear around Fedora 27 [2]. Which means that in Fedora 27 you either will be unable to build packages for epel-7 or you will have to use DNF. This is quite distant future and we will try our best to make this transition as much flawless as possible. I just want to make you aware in advance. Of course if you want to help, you are very welcome.
I expect that we will be building Fedora 22- always by yum due to short Fedora life cycle. Yum will be still present in Fedora 24 for sure.
[1] https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates [2] It’s Difficult to Make Predictions, Especially About the Future
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 22 Jan 2015 15:15:48 +0100 Miroslav Suchý msuchy@redhat.com wrote:
I just spoke with two members of DNF team about default usage of DNF in mock. I would like to share outcomes of this meeting.
First I would like to state that you can already optionally use DNF in your mock by setting: config_opts['package_manager'] = 'dnf' in your /etc/mock/site-defaults.cfg It is present in mock for half a year and all known problems have been resolved for some time. You can even set this option per chroot target. E.g. put this line only in /etc/mock/fedora-rawhide-x86_64.cfg and then only rawhide-x86_64 builds will use dnf while everything else will use yum.
DNF should be default packager manager in Fedora 22, so I started thinking how it affects mock.
I have a notion, that after branching of Fedora 22 I will change /etc/mock/fedora-rawhide-*.cfg to use DNF by default. I.e. everything build for Fedora 23 would use DNF for building.
This is not really true. Koji write out its own mock configs and will not be using dnf for any operations. for anytime soon. koji hass no way to use different tools to install chroots we will continue to use yum to install the buildroots for the foreseeable future. so it would mean that locally your builds would use dnf but in koji they will use yum.
At the outset I thought that we use yum for older targets (epel-7, fedora-22..) indefinitely. Or to be precise until those targets will be EOLed. But that would imply that yum have to be present in Fedora until Fedora 40 [1]. This is very unlikely to happen. More realistic expectation is that yum will disappear around Fedora 27 [2]. Which means that in Fedora 27 you either will be unable to build packages for epel-7 or you will have to use DNF. This is quite distant future and we will try our best to make this transition as much flawless as possible. I just want to make you aware in advance. Of course if you want to help, you are very welcome.
we use the same builders in fedora to go all the way back to epel5 and we need to ensure things still work.
I expect that we will be building Fedora 22- always by yum due to short Fedora life cycle. Yum will be still present in Fedora 24 for sure.
I am happy to sit down with you at devconf and talk about how things work for building fedora to make sure that you keep the use cases we have in releng in mind when developing mock as right now we feel like we are being served very poorly by upstream mock. There is many things to keep in mind and we need to move forward. we just need to do better about not breaking existing things that work today.
[1] https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates [2] It’s Difficult to Make Predictions, Especially About the Future
-- snip --
I have a notion, that after branching of Fedora 22 I will change /etc/mock/fedora-rawhide-*.cfg to use DNF by default. I.e. everything build for Fedora 23 would use DNF for building.
This is not really true. Koji write out its own mock configs and will not be using dnf for any operations. for anytime soon. koji hass no way to use different tools to install chroots we will continue to use yum to install the buildroots for the foreseeable future. so it would mean that locally your builds would use dnf but in koji they will use yum.
May I ask why? If you use mock that supports the config option Mirek mentioned and if you use Fedora 21 where dnf is up-to-date, are there any other technical issues that prevent you from switching the tool for some of the buildroots?
At the outset I thought that we use yum for older targets (epel-7, fedora-22..) indefinitely. Or to be precise until those targets will be EOLed. But that would imply that yum have to be present in Fedora until Fedora 40 [1]. This is very unlikely to happen. More realistic expectation is that yum will disappear around Fedora 27 [2]. Which means that in Fedora 27 you either will be unable to build packages for epel-7 or you will have to use DNF. This is quite distant future and we will try our best to make this transition as much flawless as possible. I just want to make you aware in advance. Of course if you want to help, you are very welcome.
we use the same builders in fedora to go all the way back to epel5 and we need to ensure things still work.
Again, if the conditions stated above are met, is there any other technical blocker that would prevent you from using different tool in different build root? Note that we don't propose having different builders. Yum and dnf can happily coexists on the same system.
-- snip --
Thanks Jan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 22 Jan 2015 17:00:44 +0100 Jan Zelený jzeleny@redhat.com wrote:
-- snip --
I have a notion, that after branching of Fedora 22 I will change /etc/mock/fedora-rawhide-*.cfg to use DNF by default. I.e. everything build for Fedora 23 would use DNF for building.
This is not really true. Koji write out its own mock configs and will not be using dnf for any operations. for anytime soon. koji hass no way to use different tools to install chroots we will continue to use yum to install the buildroots for the foreseeable future. so it would mean that locally your builds would use dnf but in koji they will use yum.
May I ask why? If you use mock that supports the config option Mirek mentioned and if you use Fedora 21 where dnf is up-to-date, are there any other technical issues that prevent you from switching the tool for some of the buildroots?
koji internally writes out mock configs for every task and it has not mechanism to support using different backends. additionally some of the builders are rhel6 so whatever is done has to work on rhel6 and fedora.
At the outset I thought that we use yum for older targets (epel-7, fedora-22..) indefinitely. Or to be precise until those targets will be EOLed. But that would imply that yum have to be present in Fedora until Fedora 40 [1]. This is very unlikely to happen. More realistic expectation is that yum will disappear around Fedora 27 [2]. Which means that in Fedora 27 you either will be unable to build packages for epel-7 or you will have to use DNF. This is quite distant future and we will try our best to make this transition as much flawless as possible. I just want to make you aware in advance. Of course if you want to help, you are very welcome.
we use the same builders in fedora to go all the way back to epel5 and we need to ensure things still work.
Again, if the conditions stated above are met, is there any other technical blocker that would prevent you from using different tool in different build root? Note that we don't propose having different builders. Yum and dnf can happily coexists on the same system.
it needs to work on rhel6 and would need work done in koji to support different backends. something that is not on the roadmap at all.
Dennis
-- snip --
koji internally writes out mock configs for every task and it has not mechanism to support using different backends. additionally some of the builders are rhel6 so whatever is done has to work on rhel6 and fedora.
Huh, I was under the impression that everything was already migrated from RHEL to Fedora. However I don't think it's even possible to build newer releases with such old builders, is it? If those builders are used only to build stuff like RHEL5 then there is at least some hope the transition will not be impossible :-)
-- snip --
Thanks Jan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 23 Jan 2015 18:40:11 +0100 Jan Zeleny jzeleny@redhat.com wrote:
-- snip --
koji internally writes out mock configs for every task and it has not mechanism to support using different backends. additionally some of the builders are rhel6 so whatever is done has to work on rhel6 and fedora.
Huh, I was under the impression that everything was already migrated from RHEL to Fedora. However I don't think it's even possible to build newer releases with such old builders, is it? If those builders are used only to build stuff like RHEL5 then there is at least some hope the transition will not be impossible :-)
The kernel, grub and a few other packages are built on the RHEL6 boxes, not everything was migrated off of RHEL
Dennis.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dne 23.1.2015 v 23:34 Dennis Gilmore napsal(a):
The kernel, grub and a few other packages are built on the RHEL6 boxes, not everything was migrated off of RHEL
Just out of curiosity, what are the reasons?
Vít
On Mon, 26 Jan 2015 09:43:55 +0000 Peter Robinson pbrobinson@gmail.com wrote:
The kernel, grub and a few other packages are built on the RHEL6 boxes, not everything was migrated off of RHEL
Just out of curiosity, what are the reasons?
Signing infrastructure for secure boot.
Actually, as I noted to Dennis the other day, I did move the secure boot builders over to Fedora. They are currently running Fedora 20, I still need to upgrade them to Fedora 21.
The last builders that aren't running Fedora are our ppc builders. (2 of them for epel ppc builds). I'm not sure how easy it will be to move them to Fedora.
kevin
On Mon, Jan 26, 2015 at 3:43 PM, Kevin Fenzi kevin@scrye.com wrote:
On Mon, 26 Jan 2015 09:43:55 +0000 Peter Robinson pbrobinson@gmail.com wrote:
The kernel, grub and a few other packages are built on the RHEL6 boxes, not everything was migrated off of RHEL
Just out of curiosity, what are the reasons?
Signing infrastructure for secure boot.
Actually, as I noted to Dennis the other day, I did move the secure boot builders over to Fedora. They are currently running Fedora 20, I still need to upgrade them to Fedora 21.
The last builders that aren't running Fedora are our ppc builders. (2 of them for epel ppc builds). I'm not sure how easy it will be to move them to Fedora.
The Fedora secondary PPC builders are all F-20 now, we've got some new Power8 kit coming at some point in Q1 so the plan is to move them all over to PowerKVM so we should be able to deploy all builders in the same manner across all architectures before long.
Peter
On 27. 1. 2015 at 03:54:38, Peter Robinson wrote:
On Mon, Jan 26, 2015 at 3:43 PM, Kevin Fenzi kevin@scrye.com wrote:
On Mon, 26 Jan 2015 09:43:55 +0000
Peter Robinson pbrobinson@gmail.com wrote:
The kernel, grub and a few other packages are built on the RHEL6 boxes, not everything was migrated off of RHEL
Just out of curiosity, what are the reasons?
Signing infrastructure for secure boot.
Actually, as I noted to Dennis the other day, I did move the secure boot builders over to Fedora. They are currently running Fedora 20, I still need to upgrade them to Fedora 21.
The last builders that aren't running Fedora are our ppc builders. (2 of them for epel ppc builds). I'm not sure how easy it will be to move them to Fedora.
The Fedora secondary PPC builders are all F-20 now, we've got some new Power8 kit coming at some point in Q1 so the plan is to move them all over to PowerKVM so we should be able to deploy all builders in the same manner across all architectures before long.
Does it mean that everything either migrated to Fedora or at least considered to be migrated soon?
Thanks Jan
On 27 January 2015 at 01:37, Jan Zelený jzeleny@redhat.com wrote:
On 27. 1. 2015 at 03:54:38, Peter Robinson wrote:
On Mon, Jan 26, 2015 at 3:43 PM, Kevin Fenzi kevin@scrye.com wrote:
On Mon, 26 Jan 2015 09:43:55 +0000
Peter Robinson pbrobinson@gmail.com wrote:
The kernel, grub and a few other packages are built on the RHEL6 boxes, not everything was migrated off of RHEL
Just out of curiosity, what are the reasons?
Signing infrastructure for secure boot.
Actually, as I noted to Dennis the other day, I did move the secure boot builders over to Fedora. They are currently running Fedora 20, I still need to upgrade them to Fedora 21.
The last builders that aren't running Fedora are our ppc builders. (2 of them for epel ppc builds). I'm not sure how easy it will be to move them to Fedora.
The Fedora secondary PPC builders are all F-20 now, we've got some new Power8 kit coming at some point in Q1 so the plan is to move them all over to PowerKVM so we should be able to deploy all builders in the same manner across all architectures before long.
Does it mean that everything either migrated to Fedora or at least considered to be migrated soon?
When you mean everything are you asking about web servers, database servers, email servers, etc?
Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 27. 1. 2015 at 10:03:54, Stephen John Smoogen wrote:
On 27 January 2015 at 01:37, Jan Zelený jzeleny@redhat.com wrote:
On 27. 1. 2015 at 03:54:38, Peter Robinson wrote:
On Mon, Jan 26, 2015 at 3:43 PM, Kevin Fenzi kevin@scrye.com wrote:
On Mon, 26 Jan 2015 09:43:55 +0000
Peter Robinson pbrobinson@gmail.com wrote:
> The kernel, grub and a few other packages are built on the RHEL6 > boxes, not everything was migrated off of RHEL
Just out of curiosity, what are the reasons?
Signing infrastructure for secure boot.
Actually, as I noted to Dennis the other day, I did move the secure boot builders over to Fedora. They are currently running Fedora 20, I still need to upgrade them to Fedora 21.
The last builders that aren't running Fedora are our ppc builders. (2 of them for epel ppc builds). I'm not sure how easy it will be to move them to Fedora.
The Fedora secondary PPC builders are all F-20 now, we've got some new Power8 kit coming at some point in Q1 so the plan is to move them all over to PowerKVM so we should be able to deploy all builders in the same manner across all architectures before long.
Does it mean that everything either migrated to Fedora or at least considered to be migrated soon?
When you mean everything are you asking about web servers, database servers, email servers, etc?
Build servers
Thanks Jan
Ok, I might be asking a completely stupid question here...
Why move production stuff over to dnf at all? Isn't dnf's goal in life to eventually become yum? If dnf is "good enough" to start using it in production, should the discussion be around dnf -> yum transition?
Thanks Richard
On 27 January 2015 at 10:15, Richard Shaw hobbes1069@gmail.com wrote:
Ok, I might be asking a completely stupid question here...
Why move production stuff over to dnf at all? Isn't dnf's goal in life to eventually become yum? If dnf is "good enough" to start using it in production, should the discussion be around dnf -> yum transition?
I think that was dropped a long time ago. dnf isn't going to become yum in some sort of rename. It will be a seperate command and while its syntax will be similar it is not 100% (eg you won't be able to use a yum plugin to work with dnf)
Thanks Richard
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Tue, Jan 27, 2015 at 11:25 AM, Stephen John Smoogen smooge@gmail.com wrote:
On 27 January 2015 at 10:15, Richard Shaw hobbes1069@gmail.com wrote:
Ok, I might be asking a completely stupid question here...
Why move production stuff over to dnf at all? Isn't dnf's goal in life to eventually become yum? If dnf is "good enough" to start using it in production, should the discussion be around dnf -> yum transition?
I think that was dropped a long time ago. dnf isn't going to become yum in some sort of rename. It will be a seperate command and while its syntax will be similar it is not 100% (eg you won't be able to use a yum plugin to work with dnf)
Ahh, I hadn't seen that. Well, since the name is no longer temporary I would like to say that it's a terrible name :)
Ok sorry for the noise, please continue.
Thanks, Richard
On 27. 1. 2015 at 11:29:43, Richard Shaw wrote:
On Tue, Jan 27, 2015 at 11:25 AM, Stephen John Smoogen smooge@gmail.com
wrote:
On 27 January 2015 at 10:15, Richard Shaw hobbes1069@gmail.com wrote:
Ok, I might be asking a completely stupid question here...
Why move production stuff over to dnf at all? Isn't dnf's goal in life to eventually become yum? If dnf is "good enough" to start using it in production, should the discussion be around dnf -> yum transition?
I think that was dropped a long time ago. dnf isn't going to become yum in some sort of rename. It will be a seperate command and while its syntax will be similar it is not 100% (eg you won't be able to use a yum plugin to work with dnf)
Ahh, I hadn't seen that. Well, since the name is no longer temporary I would like to say that it's a terrible name :)
:-)
FYI: http://dnf.baseurl.org/2014/03/12/on-the-name/
Jan
On Tue, 27 Jan 2015 18:09:02 +0100 Jan Zelený jzeleny@redhat.com wrote:
On 27. 1. 2015 at 10:03:54, Stephen John Smoogen wrote:
On 27 January 2015 at 01:37, Jan Zelený jzeleny@redhat.com wrote:
...snip...
Does it mean that everything either migrated to Fedora or at least considered to be migrated soon?
When you mean everything are you asking about web servers, database servers, email servers, etc?
Build servers
Well, if we can get the ppc builders over to Fedora, then they would all be running Fedora. ;)
That doesn't mean that mock on them will be using dnf by default however. That change would need to be made in koji (since it writes out the mock configs). Perhaps someone would be able to submit a koji patch around this?
Also, I am not sure the status of releng tools with dnf. That would be pungi (makes images), mash (makes repos), generic releng scripts (at https://git.fedorahosted.org/cgit/releng/ ). All those may need work to move to dnf. (Some more trivial than others)
kevin
On Wed, 28 Jan 2015 09:01:44 -0700 Kevin Fenzi kevin@scrye.com wrote:
On Tue, 27 Jan 2015 18:09:02 +0100 Jan Zelený jzeleny@redhat.com wrote:
On 27. 1. 2015 at 10:03:54, Stephen John Smoogen wrote:
On 27 January 2015 at 01:37, Jan Zelený jzeleny@redhat.com wrote:
...snip...
Does it mean that everything either migrated to Fedora or at least considered to be migrated soon?
When you mean everything are you asking about web servers, database servers, email servers, etc?
Build servers
Well, if we can get the ppc builders over to Fedora, then they would all be running Fedora. ;)
and we should be able to do that :-) In theory we support Power5 and newer hw, but there are reported problems with installing Power6 blades.
That doesn't mean that mock on them will be using dnf by default however. That change would need to be made in koji (since it writes out the mock configs). Perhaps someone would be able to submit a koji patch around this?
Also, I am not sure the status of releng tools with dnf. That would be pungi (makes images), mash (makes repos), generic releng scripts (at https://git.fedorahosted.org/cgit/releng/ ). All those may need work to move to dnf. (Some more trivial than others)
kevin
Dan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 28 Jan 2015 09:01:44 -0700 Kevin Fenzi kevin@scrye.com wrote:
On Tue, 27 Jan 2015 18:09:02 +0100 Jan Zelený jzeleny@redhat.com wrote:
On 27. 1. 2015 at 10:03:54, Stephen John Smoogen wrote:
On 27 January 2015 at 01:37, Jan Zelený jzeleny@redhat.com wrote:
...snip...
Does it mean that everything either migrated to Fedora or at least considered to be migrated soon?
When you mean everything are you asking about web servers, database servers, email servers, etc?
Build servers
Well, if we can get the ppc builders over to Fedora, then they would all be running Fedora. ;)
That doesn't mean that mock on them will be using dnf by default however. That change would need to be made in koji (since it writes out the mock configs). Perhaps someone would be able to submit a koji patch around this?
Also, I am not sure the status of releng tools with dnf. That would be pungi (makes images), mash (makes repos), generic releng scripts (at https://git.fedorahosted.org/cgit/releng/ ). All those may need work to move to dnf. (Some more trivial than others)
kevin
The work to port the releng tools to dnf has not yet been started. patches are welcome.
Dennis
On 28. 1. 2015 at 11:52:54, Dennis Gilmore wrote:
On Wed, 28 Jan 2015 09:01:44 -0700 Kevin Fenzi kevin@scrye.com wrote:
On Tue, 27 Jan 2015 18:09:02 +0100 Jan Zelený jzeleny@redhat.com wrote:
On 27. 1. 2015 at 10:03:54, Stephen John Smoogen wrote:
On 27 January 2015 at 01:37, Jan Zelený jzeleny@redhat.com wrote:
...snip...
Does it mean that everything either migrated to Fedora or at least considered to be migrated soon?
When you mean everything are you asking about web servers, database servers, email servers, etc?
Build servers
Well, if we can get the ppc builders over to Fedora, then they would all be running Fedora. ;)
That doesn't mean that mock on them will be using dnf by default however. That change would need to be made in koji (since it writes out the mock configs). Perhaps someone would be able to submit a koji patch around this?
I understand that and I will do my best to coordinate the effort here. I'm sure we will be able to provide some patches.
Also, I am not sure the status of releng tools with dnf. That would be pungi (makes images), mash (makes repos), generic releng scripts (at https://git.fedorahosted.org/cgit/releng/ ). All those may need work to move to dnf. (Some more trivial than others)
kevin
The work to port the releng tools to dnf has not yet been started. patches are welcome.
Actually, it has, at least to some degree. We work closely with Dan Mach and we already track a bunch of RFEs for hawkey. I don't know which tools are being worked on though, the only one I'm sure about is pungi.
Thanks Jan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 29 Jan 2015 10:11 +0100 Jan Zelený jzeleny@redhat.com wrote:
On 28. 1. 2015 at 11:52:54, Dennis Gilmore wrote:
On Wed, 28 Jan 2015 09:01:44 -0700 Kevin Fenzi kevin@scrye.com wrote:
On Tue, 27 Jan 2015 18:09:02 +0100 Jan Zelený jzeleny@redhat.com wrote:
On 27. 1. 2015 at 10:03:54, Stephen John Smoogen wrote:
On 27 January 2015 at 01:37, Jan Zelený jzeleny@redhat.com wrote:
...snip...
Does it mean that everything either migrated to Fedora or at least considered to be migrated soon?
When you mean everything are you asking about web servers, database servers, email servers, etc?
Build servers
Well, if we can get the ppc builders over to Fedora, then they would all be running Fedora. ;)
That doesn't mean that mock on them will be using dnf by default however. That change would need to be made in koji (since it writes out the mock configs). Perhaps someone would be able to submit a koji patch around this?
I understand that and I will do my best to coordinate the effort here. I'm sure we will be able to provide some patches.
It is going to take quite a bit of thought and effort on how to best integrate. it is something I am planning to get on a roadmap for koji 2.0
Also, I am not sure the status of releng tools with dnf. That would be pungi (makes images), mash (makes repos), generic releng scripts (at https://git.fedorahosted.org/cgit/releng/ ). All those may need work to move to dnf. (Some more trivial than others)
kevin
The work to port the releng tools to dnf has not yet been started. patches are welcome.
Actually, it has, at least to some degree. We work closely with Dan Mach and we already track a bunch of RFEs for hawkey. I don't know which tools are being worked on though, the only one I'm sure about is pungi.
Daniel Mach does not work with Fedora Releng at all. He has not communicated to me nor has anyone else. As upstream for pungi and the Fedora releng tools I think I am in a pretty good place to know where the tools are. If someone is going off and doing something without working with me then I am unaware of the work and look forward to seeing patches submitted for review.
Dennis
> Does it mean that everything either migrated to Fedora or at > least considered > to be migrated soon?
When you mean everything are you asking about web servers, database servers, email servers, etc?
Build servers
Well, if we can get the ppc builders over to Fedora, then they would all be running Fedora. ;)
That doesn't mean that mock on them will be using dnf by default however. That change would need to be made in koji (since it writes out the mock configs). Perhaps someone would be able to submit a koji patch around this?
I understand that and I will do my best to coordinate the effort here. I'm sure we will be able to provide some patches.
It is going to take quite a bit of thought and effort on how to best integrate. it is something I am planning to get on a roadmap for koji 2.0
Also, I am not sure the status of releng tools with dnf. That would be pungi (makes images), mash (makes repos), generic releng scripts (at https://git.fedorahosted.org/cgit/releng/ ). All those may need work to move to dnf. (Some more trivial than others)
kevin
The work to port the releng tools to dnf has not yet been started. patches are welcome.
Actually, it has, at least to some degree. We work closely with Dan Mach and we already track a bunch of RFEs for hawkey. I don't know which tools are being worked on though, the only one I'm sure about is pungi.
Daniel Mach does not work with Fedora Releng at all. He has not communicated to me nor has anyone else. As upstream for pungi and the Fedora releng tools I think I am in a pretty good place to know where the tools are. If someone is going off and doing something without working with me then I am unaware of the work and look forward to seeing patches submitted for review.
I would like to also point out that there is a Fedora build systems mailing list [1] where the discussions should happen and where patches should be sent for review. I've not seen any discussion, patches or anything else discussed there regarding any of the above.
Peter
[1] https://lists.fedoraproject.org/pipermail/buildsys/2015-February/thread.html
On 01/22/2015 03:58 PM, Dennis Gilmore wrote:
This is not really true. Koji write out its own mock configs and will not be using dnf for any operations. for anytime soon. koji hass no way to use different tools to install chroots we will continue to use yum to install the buildroots for the foreseeable future. so it would mean that locally your builds would use dnf but in koji they will use yum.
OK. We can postpone this change in Koji/mock for Fedora 24 or even later. But I wanted to state that because of long life of RHEL, this has to be done someday. It can be now, in half a year or in two years, but it is inevitable. Even if that would mean some changes in Koji. I raised this in advance so no one is surprised and we have time to prepare our tools in whole chain.
I am happy to sit down with you at devconf and talk about how things work for building fedora to make sure that you keep the use cases we have in releng in mind when developing mock as right now we feel like we are being served very poorly by upstream mock.
*nod*
On Thu, Jan 22, 2015 at 03:15:48PM +0100, Miroslav Suchý wrote:
I just spoke with two members of DNF team about default usage of DNF in mock. I would like to share outcomes of this meeting.
First I would like to state that you can already optionally use DNF in your mock by setting: config_opts['package_manager'] = 'dnf' in your /etc/mock/site-defaults.cfg It is present in mock for half a year and all known problems have been resolved for some time.
I've been using dnf in mock. It mostly works nicely, and the nosync plugin is a killer feature for me, it makes mock builds almost as fast as 'fedpkg local'. I encounter a bug though where /tmp/<something>/lib/nosync.so is reported linked into compiled binaries (#1184964), but it appears to be just a cosmetic issue. Maybe you should consider turning nosync on too?
You can even set this option per chroot target. E.g. put this line only in /etc/mock/fedora-rawhide-x86_64.cfg and then only rawhide-x86_64 builds will use dnf while everything else will use yum.
DNF should be default packager manager in Fedora 22, so I started thinking how it affects mock.
I have a notion, that after branching of Fedora 22 I will change /etc/mock/fedora-rawhide-*.cfg to use DNF by default. I.e. everything build for Fedora 23 would use DNF for building.
I think that is reasonable.
Zbyszek
On Thu, 22 Jan 2015 15:15:48 +0100, Miroslav Suchý wrote:
I just spoke with two members of DNF team about default usage of DNF in mock. I would like to share outcomes of this meeting.
First I would like to state that you can already optionally use DNF in your mock by setting: config_opts['package_manager'] = 'dnf'
I've switched back to Yum for now.
I expect that we will be building Fedora 22- always by yum due to short Fedora life cycle. Yum will be still present in Fedora 24 for sure.
Is DNF within Mock a fully compatible replacement for Yum yet? It seems builds take much longer now since something's downloading (or redownloading?) lots of data for each build job before setting up the buildroot. I don't have much time to look into it, bug shouldn't Mock's buildroot cache files be fresh enough to avoid redownloading packages, for example?
On 03/15/2015 02:38 PM, Michael Schwendt wrote:
On Thu, 22 Jan 2015 15:15:48 +0100, Miroslav Suchý wrote:
I just spoke with two members of DNF team about default usage of DNF in mock. I would like to share outcomes of this meeting.
First I would like to state that you can already optionally use DNF in your mock by setting: config_opts['package_manager'] = 'dnf'
I've switched back to Yum for now.
I expect that we will be building Fedora 22- always by yum due to short Fedora life cycle. Yum will be still present in Fedora 24 for sure.
Is DNF within Mock a fully compatible replacement for Yum yet? It seems builds take much longer now since something's downloading (or redownloading?) lots of data for each build job before setting up the buildroot. I don't have much time to look into it, bug shouldn't Mock's buildroot cache files be fresh enough to avoid redownloading packages, for example?
Redownloading packages is DNF default setting [1], which you can adjust in mock config. I personally use caching proxy to avoid this problem and share packages between multiple chroots.
[1] http://dnf.readthedocs.org/en/latest/conf_ref.html#keepcache-label
On 2015-03-16 06:43, Mikolaj Izdebski wrote:
On 03/15/2015 02:38 PM, Michael Schwendt wrote:
On Thu, 22 Jan 2015 15:15:48 +0100, Miroslav Suchý wrote:
I just spoke with two members of DNF team about default usage of DNF in mock. I would like to share outcomes of this meeting.
First I would like to state that you can already optionally use DNF in your mock by setting: config_opts['package_manager'] = 'dnf'
I've switched back to Yum for now.
I expect that we will be building Fedora 22- always by yum due to short Fedora life cycle. Yum will be still present in Fedora 24 for sure.
Is DNF within Mock a fully compatible replacement for Yum yet? It seems builds take much longer now since something's downloading (or redownloading?) lots of data for each build job before setting up the buildroot. I don't have much time to look into it, bug shouldn't Mock's buildroot cache files be fresh enough to avoid redownloading packages, for example?
Redownloading packages is DNF default setting [1], which you can adjust in mock config. I personally use caching proxy to avoid this problem and share packages between multiple chroots.
Configurations shipped with current mock have keepcache=1 by default, so the redownloading shouldn't happen if you have yum_cache enabled. But if you use different configs than the default ones, you'll need to adjust the config manually.
Technically, yum_cache wans't "ported" to dnf, but due to the similarity of the two package managers, if the cachedir is set to /var/cache/yum (which it is in the shipped configs), it should work without changes.
Michael Simacek
[1] http://dnf.readthedocs.org/en/latest/conf_ref.html#keepcache-label
On 03/16/2015 12:32 PM, Michael Šimáček wrote:
Configurations shipped with current mock have keepcache=1 by default, so the redownloading shouldn't happen if you have yum_cache enabled. But if you use different configs than the default ones, you'll need to adjust the config manually.
Right. This is quite new change in mock and I didn't know about it because I don't use default configs.
On Mon, 16 Mar 2015 12:32:41 +0100, Michael Šimáček wrote:
Configurations shipped with current mock have keepcache=1 by default, so the redownloading shouldn't happen if you have yum_cache enabled. But if you use different configs than the default ones, you'll need to adjust the config manually.
It's the default with a local buildroot override repo added (cost=0 and metadata_expire=0). That has worked flawlessly for several years.
I've tried to take a look at it a few times with extra Mock runs. The "dnf update" step for the Rawhide build target has been choking while downloading metadata from very slow mirrors as well as downloading up to 176 packages before the builddeps step. For every build job. When I interrupted everything and restarted from scratch, it repopulated the buildroot cache and did not download any updates anymore for subsequent build jobs. I'm puzzled. Could it be that we've been assigned to a semi-broken set of rawhide mirrors for some time?
On 03/15/2015 02:38 PM, Michael Schwendt wrote:
Is DNF within Mock a fully compatible replacement for Yum yet? It seems builds take much longer now since something's downloading (or redownloading?) lots of data for each build job before setting up the buildroot. I don't have much time to look into it, bug shouldn't Mock's buildroot cache files be fresh enough to avoid redownloading packages, for example?
yum_cache plugin was not migrated to DNF yet. This can affect first build, but should not affect next builds.