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-0008.html>