On Thu, May 18, 2017 at 7:32 AM, Fabian Arrotin arrfab@centos.org wrote:
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@redhat.com mailto:sbonazzo@redhat.com> wrote:
On Thu, Mar 16, 2017 at 6:17 PM, Fabian Arrotin <arrfab@centos.org <mailto:arrfab@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 factthat there
>> isn't even a policy around Extras repository now. So it's upto the
>> people allowed to build/sign/push to know what they'll addin Extras,
>> and only in the arches they care about. > > https://wiki.centos.org/AdditionalResources/Repositories <https://wiki.centos.org/AdditionalResources/Repositories> hasa
> definition for the Extras repos. on C7 it should include whatis
> upstream in the Extras/ repos ( provided we are able to buildit ), and
> other things that are needed sometimes to build content inbase / updates.
> > In addition to this, Extras should contain allcentos-release-* files
> from the SIG's. > > The only other content that should make it into Extras shouldbe content
> vetted by the core sig, considered fundamental to userexperience or
> tooling for user experience. ie. a fairly high barrier toentry.
> > Does that give us enough policy wording for Extras ? Do wehave
> 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, sothat
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@centos.org <mailto:CentOS-devel@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 ?
I think it's mostly it. Thanks for summarizing.
-- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel