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=$basearch metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=$basearch metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-testing-f$releasever&arch=$basearch metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-debug-$releasever&arch=$basearch metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f$releasever&arch=$basearch metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-testing-debug-f$releasever&arch=$basearch 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 > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/buildsys -- buildsys mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/buildsys
