On Mon, Mar 13, 2017 at 09:10:32PM +0100, 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.
It would be really nice to have this available. Personally I care most for armv7hl because that is hardware I have and am actively using. Because the process for armv7hl does not seem very automated (or matches the rest of the altarch workflow), I am currently 'stuck' on Fedora.
However there are many others in the Gluster community that run the GlusterFS packages on different hardware. Because CentOS does not provide the repositories (or have not announced it well enough?), I only see non-x86_64 problem reports and questions on other distributions. It would be great to see more Gluster users running on CentOS/altarch.
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.
For the Gluster repositories from the Storage SIG, it is even acceptible to block on altarch. I think it is unlikely that an update for the packages in the Gluster repositories would introduce new problems with altarch packages, or teh other way around. When there is a major release, new dependencies might be needed, but there should be enough time to get those available in -extras or somewhere else.
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.
I prefer to see everything build (at least for Gluster) against all arches. This is what we do for many other distributions too, and we are committed to fix problems there as well.
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.
Works for me too, as long as I do not have to take additional actions to get packages available for CentOS/altarch users.
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.
Sounds good, but there is one more thing that needs to be mentioned. I would like to have the ability (I'm pretty sure it is coming?) to test the altarch packages in the CI. It is not an absolute requirement for the beginning, but it is definitely something to consider. It would allow testing interoperability between different architectures (yay for low level network protocols :-/).
Is altarch-extras important to you ?
Yes, and as seen in Sandros email from earlier today, the -extras being out of sync causes problems for some of the SIGs. Thanks for testing Sandro! https://lists.centos.org/pipermail/centos-devel/2017-March/015736.html (+python-pretty-table is missing in -extras.ppc64le for Gluster 3.10)
Cheers, Niels