Personnaly I'm waiting for a while for 32bits packages in extra "and" Epel. So, I will appreciate.
De : Thomas Oulevey thomas.oulevey@cern.ch À : The CentOS developers mailing list. centos-devel@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,