On 02/24/2015 08:47 AM, Honza Horak wrote:
On 02/23/2015 08:39 PM, Thomas Oulevey wrote:
CBS build tags in format like: sclo6-mariadb100-build sclo7-mariadb100-build
We need to keep the disttag in the name as agreed from the beginning for all SIGs: sclo6-el6-mariadb100-build sclo7-el7-mariadb100-build
OK, understood.
(scol7-el7_1-mariadb-build maybe ; However I don't remember if the SIG agreed to have 1 disttag only per distribution policy even for rhscl rebuild; which is the way to go if you ask me :).
The disttag can be some other string not containing major; e.g: .infra.
I need a way to parse it consistently and existing scripts have been written this way.
There is one piece I'm struggling with (and I'm not sure if that's the same thing you call special disttag for rhscl rebuild). It is how to deal with conflicting NVRs in koji (supposing CBS koji also doesn't allow two build tasks resulting into the same NVR).
When we build some SRPM first in sclo project and then import the same SRPM to rpms project (so we're able to build it from SCM, sign it and release), then koji build will fail, because we already have the same NVR built from SRPM, right?
I'm thinking if we can solve this by disttag, so e.g. every build from SRPM would get something like ".el6.test" and only SCM builds would get ".el6". As far as I understand koji, that would require another build target, right?
Maybe there is some nicer way to handle this or you may convince me we don't need to solve this at all and just handle it with release bumps. (just thinking loudly now)
I'm also still thinking about destination tags for sclo SIG -- currently there are those two proposed for every elX version: scloX-testing and scloX-release..
And the process (as I understand it) requires rpms first to be tagged into scloX-testing and after it tag those built from SCM into scloX-release.
I'm not sure if the middle step with scloX-testing is required for rpms coming from 'rpms' git project actually, since those should already be tested from 'sclo' git project.
So, can we actually simplify the process and tag into scloX-release right after building from 'rpms' git project?
If not, then I'd propose to have some different tag for not-yet-released rpms from the stable repos (e.g. scloX-candidate)
Then it would work like this: rpms built from 'sclo' git repos will be tagged into scloX-testing rpms built from 'rpms' git repos will be tagged first into scloX-candidate and then into sclX-release on releasing
Thoughts?
Honza