[CentOS-devel] CentOS 7 extras for alternative arches and Koji workflow.

Wed Mar 15 09:28:00 UTC 2017
Fabian Arrotin <arrfab at centos.org>

On 13/03/17 21:10, Thomas Oulevey wrote:
> Dear All,
> 
> I'd like to retake a pending issue with -extras on c7 and ask for feedback.
> 
> I wear two hats :
> 1/ User, who would like to use altarch-extras packages soon after they
> are available in c7-extras.
> 2/ CBS maintainer, who would like to provide his users consistent
> buildroot across all architecture.
> 
> Let's start with 1/. The important point here is to be able to rely on
> altarch-extras and expect it to be in sync with c7-extras in a
> reasonable time. (days not weeks)
> As it was always stated c7 (all repositories) cannot and should not be
> blocked by any alt-arch rebuild and should be independent.
> However we should at least try to provide these alt-arches packages in a
> timely manner.
> 
> A lot of coordination (and motivated contributors) is needed if this
> effort is not centralized.
> 
> For 2/ it is very important that we build package with similar
> buildroots on all arches. As c7-extras is now enabled for everybody, we
> should be able to have the altarch equivalent in a timely manner.
> Also all SIGs who are building for all alt-arches will be blocked in
> case an extras package is needed in the buildroot (we dealt with these
> issues during 7.2 -> 7.3 cycle and it will come back at next minor
> release. Additional challenge is the -cr repository which is enabled in
> CBS by default)
> 
> However I understand, we need a way not to block official c7 arches for
> other arches that need fixes.
> 
> After reviewing the possibilities with different people last year, one
> way to tackle this issue, would be to have 2 targets in Koji ; 1
> including official arches and the other including official arches +
> alt-arches and allow SIG to bypass alt-arches by changing one target in
> their config. In this config we could move easily an altarch to an
> official one and vice versa.
> 
> Finally, in my opinion, an easy way to have consistent altarch-extras
> would be to monitor official repository on the mirror.c.o (or
> buildlogs.c.o) and rebuild automatically extras packages in Koji, which
> would be picked by a script and so all altarch-extras would be generated
> directly by Koji itself and the process pretty much automated.
> 
> The signing process will still be the key to control what is pushed to
> buildlogs/mirrors. (and close to what we already do)
> 
> I don't see many disadvantages for this solution but I would like to
> know if it is possible to move forward and what the community and core
> contributors think about it.
> 
> Is altarch-extras important to you ?
> 
> thank you for your feedback,

Thanks a lot Thomas for the thread around AltArch and Extras.
It's true that it needs to be debated, and each attempt to do it through
weekly CBS meeting fails because SIGs aren't present, nor people
building/releasing for Extras either.

So my understanding is that the problem relies on the fact that there
isn't even a policy around Extras repository now. So it's up to the
people allowed to build/sign/push to know what they'll add in Extras,
and only in the arches they care about.

CBS isn't authoritative for Core distro nor Extras, so that will be a
problem.
I can understand that distro itself is built on a separate environment
(but still separated for *every* arch, which isn't ideal either ...) but
can we think about building Extras directly through CBS ? What's the
reason why we don't do this right now ? if we include Extras in the mock
buildroots for cbs, people using multiple arches should expect indeed
the same packages to be available (if not excluded due to ExclusiveArch
of course).

As a simple example, in the last weeks we (infra team) had issue with
the simple koji upgrade/update as some pkgs were built for x86_64
extras, but not other arches, so we had in a hurry to build missing
pieces to then be able to just update koji (as we have builders for
AltArches that *need* to follow now)

I personally don't like the "let's track what's released on
mirror.centos.org extras and rebuild it afterwards in cbs" idea :
doesn't that sound counter-productive to wait for a core maintainer to
build on his own, sign, push to mirror and only after rebuilding again
the same thing in cbs ? If we can build it once, it's true that we can
(re)build it multiple times, but not sure about the "win" :)


Also myself waiting for opinions/feedback on this

-- 
Fabian Arrotin
The CentOS Project | http://www.centos.org
gpg key: 56BEC54E | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20170315/447c60d6/attachment-0008.sig>