The other day someone suggested that mock should dynamically create configs from a set of templates, so that we wouldn't have to keep delivering and deleting a series of config files each time a new Fedora release goes out. Not sure who it was since I can't find the discussion in my IRC logs, but might have been dgilmore. Nirik? Don't know...
Anyway, I started thinking about it and it seems doable. Right now configs are named with three fields:
<distro>-<release>-<arch>.cfg
We could come up with templates for distro-arch that would be used to generate a config. The idea is someone invokes mock with this command line:
$ mock -r fedora-73-x86_64 --init
We go look in /etc/mock and find no fedora-73-x86_64.cfg, so we go grab /etc/mock/template/fedora-x86_64 and substitute in '73' for the release number, then write /etc/mock/fedora-73-x86_64.cfg. Then we continue on our way, at least until the build fails due to non-existant repositories (presuming that we're not talking about the year 2035 here).
Obviously you could fat-finger the release number and generate a bogus config file. Worse you might want to be using F22 but mis-type '21' and use a wrong, but existent config. Also, I don't really like the idea of dynamically creating files in /etc, so we might need to move the created configs off to a /var/mock/configs directory or something like that.
The upside though is that we could stop having to add and delete configs when new Fedora releases come out.
What do you guys think?
Clark
On related note, I never understood why this is in configs:
$ cat /etc/mock/fedora-22-x86_64.cfg | grep $releasever metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=... metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releaseve... metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-testing-f$releasever... metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-debug-$releasever&... metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f$rel... metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-testing-debug-f$rele...
I mean, is it f22 config or is it some generic config? When it says fedora-22, I'd say that the $releasever should be expanded to "22" and that should be it. The same applies to $basearch of course. Not mentioning that on same places, it is already expanded:
$ cat /etc/mock/fedora-22-x86_64.cfg | grep 22 config_opts['root'] = 'fedora-22-x86_64' config_opts['dist'] = 'fc22' # only useful for --resultdir variable subst config_opts['releasever'] = '22' gpgkey=file:///etc/pki/mock/RPM-GPG-KEY-fedora-22-primary gpgkey=file:///etc/pki/mock/RPM-GPG-KEY-fedora-22-primary baseurl=http://kojipkgs.fedoraproject.org/repos/f22-build/latest/x86_64/
Vít
Dne 29.7.2015 v 17:49 Clark Williams napsal(a):
The other day someone suggested that mock should dynamically create configs from a set of templates, so that we wouldn't have to keep delivering and deleting a series of config files each time a new Fedora release goes out. Not sure who it was since I can't find the discussion in my IRC logs, but might have been dgilmore. Nirik? Don't know...
Anyway, I started thinking about it and it seems doable. Right now configs are named with three fields:
<distro>-<release>-<arch>.cfg
We could come up with templates for distro-arch that would be used to generate a config. The idea is someone invokes mock with this command line:
$ mock -r fedora-73-x86_64 --init
We go look in /etc/mock and find no fedora-73-x86_64.cfg, so we go grab /etc/mock/template/fedora-x86_64 and substitute in '73' for the release number, then write /etc/mock/fedora-73-x86_64.cfg. Then we continue on our way, at least until the build fails due to non-existant repositories (presuming that we're not talking about the year 2035 here).
Obviously you could fat-finger the release number and generate a bogus config file. Worse you might want to be using F22 but mis-type '21' and use a wrong, but existent config. Also, I don't really like the idea of dynamically creating files in /etc, so we might need to move the created configs off to a /var/mock/configs directory or something like that.
The upside though is that we could stop having to add and delete configs when new Fedora releases come out.
What do you guys think?
Clark
buildsys mailing list buildsys@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/buildsys
Dne 30.7.2015 v 09:39 Vít Ondruch napsal(a):
On related note, I never understood why this is in configs:
$ cat /etc/mock/fedora-22-x86_64.cfg | grep $releasever metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=... metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releaseve... metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-testing-f$releasever... metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-debug-$releasever&... metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f$rel... metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-testing-debug-f$rele...
I mean, is it f22 config or is it some generic config? When it says fedora-22, I'd say that the $releasever should be expanded to "22" and that should be it. The same applies to $basearch of course. Not mentioning that on same places, it is already expanded:
I think it is good when config_opts['yum.conf'] as closely as possible copy /etc/yum.repos.d/fedora.repo In past (2 years ago) it diverged and had different baseurl (while yum.repos.d had metalink) which lead at least to one bug.
Dne 30.7.2015 v 10:21 Miroslav Suchý napsal(a):
Dne 30.7.2015 v 09:39 Vít Ondruch napsal(a):
On related note, I never understood why this is in configs:
$ cat /etc/mock/fedora-22-x86_64.cfg | grep $releasever metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=... metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releaseve... metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-testing-f$releasever... metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-debug-$releasever&... metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f$rel... metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-testing-debug-f$rele...
I mean, is it f22 config or is it some generic config? When it says fedora-22, I'd say that the $releasever should be expanded to "22" and that should be it. The same applies to $basearch of course. Not mentioning that on same places, it is already expanded:
I think it is good when config_opts['yum.conf'] as closely as possible copy /etc/yum.repos.d/fedora.repo In past (2 years ago) it diverged and had different baseurl (while yum.repos.d had metalink) which lead at least to one bug.
In that case, may be you should introduce $fedorarepofile variable and use it as a placeholder for /etc/yum.repos.d/fedora.repo. I don't think copy pasting the information around is the best practice.
And actually, neither I think this is good practice for /etc/yum.repos.d/fedora.repo, since you cannot query various Fedora releases at once.
Vít
Dne 30.7.2015 v 10:46 Vít Ondruch napsal(a):
In that case, may be you should introduce $fedorarepofile variable and use it as a placeholder for /etc/yum.repos.d/fedora.repo. I don't think copy pasting the information around is the best practice.
How do you define content of this variable for Fedora 23 on RHEL6? And vice versa.
Additionally in yum.repos.d there is: fedora.repo, fedora-updates.repo... while mock config have it concatenated.
Additionally yum.repos.d does not have defined [local] section.
I have to say that I have desperately wanted a way to make every mock config use my local mirror instead of having to edit every file. Having the repo definitions.in some generic place would make things much simpler.
Which I know is the exact opposite of what Vit was suggesting, but I figure I'd toss in my use case.
- J<
-----Original Message----- Subject: Re: RFC: dynamic generation of mock config from template?
I have to say that I have desperately wanted a way to make every mock config use my local mirror instead of having to edit every file. Having the repo definitions.in some generic place would make things much simpler.
Which I know is the exact opposite of what Vit was suggesting, but I figure I'd toss in my use case.
I'm in the same boat, but have no pain here at all. I have puppet spew out my mock configs from a template. I merely create a new stanza that has the few details that differ for each release and those are obvious simply by looking at the ones I've already created. If puppet is too heavy, you could do the same with ansible instead (or a masterless puppet for that matter). Have you considered something along these lines?
-- John Florian
On Fri, 31 Jul 2015 19:52:00 +0000 John Florian john.florian@dart.biz wrote:
-----Original Message----- Subject: Re: RFC: dynamic generation of mock config from template?
I have to say that I have desperately wanted a way to make every mock config use my local mirror instead of having to edit every file. Having the repo definitions.in some generic place would make things much simpler.
Which I know is the exact opposite of what Vit was suggesting, but I figure I'd toss in my use case.
I'm in the same boat, but have no pain here at all. I have puppet spew out my mock configs from a template. I merely create a new stanza that has the few details that differ for each release and those are obvious simply by looking at the ones I've already created. If puppet is too heavy, you could do the same with ansible instead (or a masterless puppet for that matter). Have you considered something along these lines?
Even simpler, I generate all of mine from a simple shell script and an m4 template.
Paul.
Dne 29.7.2015 v 17:49 Clark Williams napsal(a):
Obviously you could fat-finger the release number and generate a bogus config file. Worse you might want to be using F22 but mis-type '21' and use a wrong, but existent config. Also, I don't really like the idea of dynamically creating files in /etc, so we might need to move the created configs off to a /var/mock/configs directory or something like that.
And what about GPG keys?
[local] section in yum.conf for primary and secondary architectures differ. And for example in case of ppc64le you could not easily substitute $arch in that Koji url.
Two years ago we changed mirrolist to metalink. Today we are changing yum to dnf. All this need changes in config. I assume that in two years the template would need some other change. So the template last just four Fedora releases.
I think that while it is technically doable, it would lead just to confusion and IMHO the cons will overweight the pros.
buildsys@lists.fedoraproject.org
-
Clark Williams -
Jason L Tibbitts III -
John Florian -
Miroslav Suchý -
Paul Howarth -
Vít Ondruch