On Monday, May 25, 2015 08:45:21 AM Miroslav Suchý wrote:
Dne 23.5.2015 v 01:27 Dennis Gilmore napsal(a):
> That is not a workable solution. we have to overwrite the
> site-defaults.cfg
I disagree here. But I'm not the one who operate the Koji.
I think I am doing a
very poor job of explaining myself
today we have to set some options in the site-defaults.cfg file
cat /etc/mock/site-defaults.cfg
config_opts['plugin_conf']['package_state_enable'] = False
config_opts['plugin_conf']['ccache_enable'] = False
maybe we do not need to explicitly disable ccache but we do. this is managed
in ansible. so now we need to make two copies of the site-defaults.cfg file.
first we have to know we need to do it(which we clearly do, but other koji
users may not) then second whenever we update the site-defaults.cfg, which is
not often we need to remember we have to make the change twice. unless of
course we can use the dafult which we can not. the package_state_enable plugin
was causing build failures and was duplicating work koji does internally, so
we disabled it.
an example from fedora's koji setup, the arm, and x86 builders are all running
Fedora 21, the ppc builders are running rhel. so for all the epel targets we
would need to set the backend to be yum. but something on the fedora builders
needs to know to translate yum to yum-deprecated.
I think that we have to assume that more backends will come along, apt or
zypper or some other distros tool or a new one we write to replace dnf. So I
strongly believe that the solution needs to be flexible to allow for future
unknown changes.
I think it is reasonable to set the backend to yum-deprecated. To me the way
to support this should be in mock based on the host os. we know there is a
mapping between yum and yum-deprecated, if the host is f22 and newer or EL8
and newer when you say yum you really mean yum-deprecated and if you say yum-
deprecated on something older you really mean yum. To me doing that outside of
the code while it works for some cases it's not flexible.
> and have it work across rhel and fedora builders in fedora. the
solution
> really needs to be a combination of things. I think the koji code needs to
> assume that there could be multiple possible backends, so we can set yum,
> yum- deprecated, dnf. but additionally mock needs to really know that if
> the host is f22 or newer or rhel8(big assumption here) or newer and you
> say yum is the
The decision of mock is config driven. And mock ships different config for
different distribution.
> backend you mean yum-deprecated. I am assuming yum-deprectaed will be in
> one of RHEL or EPEL.
DNF (with yum-deprecated) is in EPEL (however just EPEL7), but there is no
dnf-plugins-core, which is needed too.
Can you or somebody else from rel-engs alter my patch or come with different
solution? I would like to remind that according
https://fedorahosted.org/rel-eng/ticket/6162
we have just 3 weeks to do that in F23 time-frame. Then it will be again too
late, and you will have to target for F24.
https://fedoraproject.org/wiki/FAD_Release_Tools_and_Infrastructure_2015#...
it is one of the deliverables for the FAD next week. we do want a solution. I
will try comeup with something I see as a workable option. but someone else is
free to do something also. Thank you for taking a stab at it
Dennis