On related note, I never understood why this is in configs:
$ cat /etc/mock/fedora-22-x86_64.cfg | grep \$releasever
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
config_opts['releasever'] = '22'
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:
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
$ 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
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
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?
buildsys mailing list