Hi, Le 03/03/2017 à 12:20, Javier Pena a écrit : > > > ----- Original Message ----- >> Hi >> >> Le 27/02/2017 à 17:50, Fabien Boucher a écrit : >>> Hello, >>> >>> As we have started the effort to have all components, bundled in the SF >>> image, packaged >>> we are figuring out that EPEL and RDO repo are helpful as a bunch of >>> dependencies are >>> available there. Unfortunately on a SF installation if yum is freely usable >>> then >>> an operator can break its SF deployment if EPEL or RDO lands something that >>> break >>> an ABI. >>> >>> Usually it should not happen with EPEL as explain in the upgrade policy: >>> https://fedoraproject.org/wiki/EPEL_Updates_Policy >>> https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies >>> >>> RDO have stable releases that should not introduce ABI breakages over the >>> time. >>> >>> Relying on both EPEL and RDO can increase the risk so it may be better to >>> only >>> rely on one of them and RDO includes stuff we care about like olso, >>> openstack clients ... (+ a lot of pkg from EPEL) so better to only rely on >>> RDO IMO. >>> >>> Also there's the solution of only relying on base centos managing the >>> deps by ourself but the work seems quite huge for a small team ... ? >> >> What about, in that case, having the distro.yaml file that describes the SRPM >> list >> like : >> >> extra-srpms: >> - >> >> http://cbs.centos.org/kojifiles/packages/python-pecan/1.1.2/1.el7/noarch/python2-pecan-1.1.2-1.el7.noarch.rpm >> - >> >> http://cbs.centos.org/kojifiles/packages/python-oslo-policy/1.18.0/1.el7/src/python-oslo-policy-1.18.0-1.el7.src.rpm >> - ... >> >> That way we will have a self-sufficient SF RPM repo, like RDO where only base >> and update centos >> repo are needed. >> >> We will need to take care of also adding the Build and Runtime deps for what >> we include in extra-srpms. >> >> A job, well a script, must fetch the srpms and build them in the specific >> target. If a srpms is already >> referenced in the target simply skip. If one has change (version changed) >> then: >> - koji remove-pkg >> - koji build > > I think this would work fine. I'm only concerned at how long will the srpm > files stay in CBS, do you know if they are purged when they are old? > > Javier
Good question. This can be a blocker if a target need to be rebuilt later. I just checked on cbs and koji.fedoraproject.org and: As id are incremental http://cbs.centos.org/koji/buildinfo?buildID=10 https://koji.fedoraproject.org/koji/buildinfo?buildID=10 Both have a working srpm link. The latter is a task of 2007. So I guess by default there isn't any policies for cleaning them. Fabien >> >>> Also after discussing with Nico it can be safer to only enable >>> centos-update and >>> sf RPM repos and disable the rest at the end of the built of the image to >>> avoid eventual unexpected pkg bumps from RDO or even EPEL according to our >>> choice. >>> >>> Cheers, >>> Fabien >>> >> >> _______________________________________________ >> Softwarefactory-dev mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/softwarefactory-dev >> _______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
