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

john tatt zikamev at yahoo.com
Tue Mar 14 10:32:13 UTC 2017


Personnaly I'm waiting for a while for 32bits packages in extra "and" Epel.
So, I will appreciate.


      De : Thomas Oulevey <thomas.oulevey at cern.ch>
 À : The CentOS developers mailing list. <centos-devel at centos.org> 
 Envoyé le : Lundi 13 mars 2017 21h10
 Objet : [CentOS-devel] CentOS 7 extras for alternative arches and Koji workflow.
   
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,
-- 
Thomas Oulevey
_______________________________________________
CentOS-devel mailing list
CentOS-devel at centos.org
https://lists.centos.org/mailman/listinfo/centos-devel


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20170314/b6c734d1/attachment.html>


More information about the CentOS-devel mailing list