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#Deliverables 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
signature.asc
Description: This is a digitally signed message part.
-- buildsys mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/buildsys
