On 18/05/17 00:49, Karanbir Singh wrote: > On 08/05/17 13:44, Sandro Bonazzola wrote: >> >> >> On Fri, Mar 17, 2017 at 10:49 AM, Sandro Bonazzola <sbonazzo at redhat.com >> <mailto:sbonazzo at redhat.com>> wrote: >> >> >> >> On Thu, Mar 16, 2017 at 6:17 PM, Fabian Arrotin <arrfab at centos.org >> <mailto:arrfab at centos.org>> wrote: >> >> On 15/03/17 16:58, Karanbir Singh wrote: >> > On 15/03/17 09:28, Fabian Arrotin wrote: >> > >> >> 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. >> > >> > https://wiki.centos.org/AdditionalResources/Repositories >> <https://wiki.centos.org/AdditionalResources/Repositories> has a >> > definition for the Extras repos. on C7 it should include what is >> > upstream in the Extras/ repos ( provided we are able to build it ), and >> > other things that are needed sometimes to build content in base / updates. >> > >> > In addition to this, Extras should contain all centos-release-* files >> > from the SIG's. >> > >> > The only other content that should make it into Extras should be content >> > vetted by the core sig, considered fundamental to user experience or >> > tooling for user experience. ie. a fairly high barrier to entry. >> > >> > Does that give us enough policy wording for Extras ? Do we have >> > exceptions we need to work through ? >> > >> >> Sounds good. So with that definition in mind, how can we be sure >> that >> Extras is then built/distributed in parallel for all arches, so that >> then it can be safely enabled within CBS ? >> >> -- >> Fabian Arrotin >> The CentOS Project | http://www.centos.org >> gpg key: 56BEC54E | twitter: @arrfab >> >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org <mailto:CentOS-devel at centos.org> >> https://lists.centos.org/mailman/listinfo/centos-devel >> <https://lists.centos.org/mailman/listinfo/centos-devel> >> >> >> >> Adding here notes I sent in a different thread, for reference. >> I'm facing some discrepancies in repositories structure for ppc64le. >> >> In x86_64 qemu-kvm-ev is shipped within >> http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/ >> <http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/> >> which is the path I was expecting. Now, looking at ppc64le I see it >> shipped within: >> http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/ >> <http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/> >> and being extras enabled by default it overrides qemu-kvm shipped by >> core os. >> Can we at least replicate the same structure between >> http://mirror.centos.org/centos/7 >> <http://mirror.centos.org/centos/7> and http://mirror.centos.org/altarch/7 >> <http://mirror.centos.org/altarch/7> ? >> >> >> Any update? > > have you tried to reach out to the SIG's responsible for the content ? > That's interesting, as for ppc64/ppc64le for AltArch SIG, you're the one responsible KB for those arches (from what I see on https://wiki.centos.org/SpecialInterestGroup/AltArch) So I guess that yes, Sandro tried to reach out and contact you for that question :-) When it was discussed at the CBS meeting, (but lot of involved people weren't there, it was clearly shown that we lack a process for Extras, and ensuring then than all Alt Arches are following the authoritative x86_64 distro. That was becoming a problem too as in fact, nothing from Extras is built on cbs, but rather on different builders and different processes (so more or less like @core distro) The issue that people were seeing was that they wanted to have Extras enabled within CBS, but due to lack of consistency in Extras, some builds could fail just because one package is missing from Extras for an arch, while being available for x86_64. Does that summarize the issue SIGs members reported in #centos-devel but also earlier on this list ? -- 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/20170518/4d8a69de/attachment-0008.sig>