[scl.org] Component name in non-RH dist-gits
rcollet at redhat.com
Tue Feb 17 08:21:25 UTC 2015
Le 17/02/2015 08:52, Honza Horak a écrit :
> I'm thinking about repositories and branches structure in CentOS a bit
> Currently, there are two ways how components names and branches are
> maintained in SCL world:
> A) collection name in branch name
> we use component name without prefix in dist-git and branches for
> specific collections internally in RH, so e.g. mariadb has branches for
> mariadb55-*, rh-mariadb100-*, etc..
> B) collection name in dist-git repository name
> For RHSCL RPMs that are automatically imported into
> https://git.centos.org , components *use* prefix in repository names
> and static set of branches. For example mariadb55-mariadb component
> includes branches 'master' and 'c7' . This way seems easier for
> dist-git administration and also seems to be preferred way in Fedora .
> Since we can always add remote branches in (B) and merge/cherry-pick
> from those as easy as we can in (A), my question is:
> "Are there any practical advantages of (A)?"
> I don't see any, but I see some advantages of (B) though, since it seems
> to be more consumable to use the same approach (B) in all public repos
> and only use (A) internally only for historic reasons.
(A) make sense to me, as the same package/spec can be used in various
Ex: php-pear, various branches
With (B) we need 4 repositories
Of course, for historical reason (packages pulled from Fedora where SCL
are not allowed), base packages are really different from SCL packages.
But SCL packages are really similar in the different collections.
But (B) is not really a problem, in fact I mostly never have to
cherry-pick from different branches.
But in some other repo, I use "exactly" the same spec for all targets.
> Does it make sense to you as well?
> [no response means yes to me :) ]
>  https://git.centos.org/tree/rpms!mariadb55-mariadb/c7
> SCLorg mailing list
> SCLorg at redhat.com
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