[scl.org] Workflow for Software Collections (SCLs) in CentOS
Remi Collet
rcollet at redhat.com
Tue Feb 24 08:53:20 UTC 2015
Le 23/02/2015 18:44, Honza Horak a écrit :
> This proposal considers the following:
> * we want to provide stable SCLs rebuilt from RHSCL for CentOS users
> * we want to have a platform for upstream development for collections
> that:
> - will be part of the future RHSCL (same SCL name as in RHSCL uses,
> RH developers own those, others may contribute -- send patches)
> - have been part of RHSCL but will get some update eventually, so we
> want to test the fixes before applying in RHSCL
> - are not intended for RHSCL (those won't use "rh-" prefix [2], but
> should have some other prefix)
>
>
> Some technical details of CentOS Build Service (CBS) at [3]
> =============================================================================
>
> There are several projects in centos distgit (http://git.centos.org),
> those two are important for SCL:
> * sclo -- code of testing packages, uses fedora layout (specfile and
> sources directly in the repository, no directories), building rpms in
> CBS only from srpm, final rpms are testing only (tagged into sclX-testing)
> * rpms -- code of stable packages, centos layout (specfile and sources
> in SPECS, SOURCES directories), building rpms in CBS either from srpm or
> from scm, possible to build official rpms (tagged into sclX-release,
> request signing and releasing)
>
> There are two koji tags set for all collections for every elX version (X
> is 6, 7, ...el6, el7, ...):
> * sclX-testing: default tag where all built srpms are tagged into
> * sclX-release: only rpms built from scm can be tagged here (and will
> be signed)
>
>
> Workflow schema:
> ================
>
> git.c.o CBS scl.org [1]
> -----------------------------------------
> develop in
> sclo project
> | \
> | \
> | build from srpm
> | for testing only
> | |
> | |
> | rpm tagged into
> | sclX-testing
> | \
> | \
> | available in
> | sclo-testing
> | repo
> |
> |
> import srpm
> into rpms
> project
> \
> \
> build release
> candidate
> from scm
> |
> |
> tagged into
> sclX-testing
> \
> \
> available in
> sclo-testing
> repo
> /
> /
> tag into
> sclX-release
> sign & release
> \
> \
> available in
> sclo-stable
> repo
>
>
> Description of the scheme above
> ===============================
> Workflow during development phase:
> ----------------------------------
> * this part is valid for future RHSCL collections that (both net new
> and major update) are not yet available in RHSCL
> * contributors prepare new collection under sclo project
> * contributors build testing rpms from srpm
> * rpms are tagged into sclX-testing
> * scl.org [1] imports specific collections from sclX-testing
>
> Workflow during maintainance phase:
> --------------------------------
> * this part is valid for collections that are/were released
> * contributors prepare patches under sclo project to test them before
> applying (in RHSCL or non-RH stable SCL) -- fix smaller bugs, extend
> stable collection in compatible mode, generally maintain compatibility
> of the collection
> * contributors build testing rpms from srpm
> * rpms are tagged into sclX-testing
> * srpms are manually imported from sclo to rpms project @ git.c.o
> * contributors build official packages from scm and tag them into
> sclX-release
> * contributors ask for signing and publishing
> * scl.org imports specific collections from sclX-release and
> potentially also from sclX-testing
>
> Specific for RH collections:
> ----------------------------
> srpm can be automatically imported to rpms project or even to sclo
> project on errata publishing if maintainer wishes so
Question about NEVR
The NEVR (in the spec) will probably be the same in the devel phase
(git/sclo) and after (git/rpms).
Isn't this going to be a problem ?
Does the %{?dist} need to be different ?
I think Koji will not accept a build with the same NEVR.
> Some open questions
> ===================
> Q: scl.org to provide a separate repository for each collection? or one
> repository for all collections in -testing?
> Proposal: we can start with one common repository for all stable centos
> collections, the same we do in RHSCL?
+1 for a single repository, else it will be a nightmare for use of
dependent collection (ex php55 / httpd24)
>
> Q: what about centos vs epel?
> Proposal: if there are some packages that want to use centos collections
> in the future, epel should start to build above centos' sclo repos.
EPEL build against RHEL, so should build against RHSCL.
Remi
> That
> means the same collections don't need to be build again in epel. How is
> it done in other centos SIGs in case they provide the same components in
> epel?
>
> [1] https://www.softwarecollections.org/en/scls/
> [2] https://www.redhat.com/archives/sclorg/2015-February/msg00022.html
> [3] http://cbs.centos.org
>
> Honza
>
> _______________________________________________
> SCLorg mailing list
> SCLorg at redhat.com
> https://www.redhat.com/mailman/listinfo/sclorg
--
rcollet at redhat.com | Senior Software Engineer / BaseOS / WebStack team
GPG Key: 0x29F16A18
Fingerprint: 5A0E 6F54 D94D 5732 69EE E3FF 614A 6905 29F1 6A18
More information about the SCLorg
mailing list