On Thu, May 18, 2017 at 7:32 AM, Fabian Arrotin <arrfab at 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 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 ? > 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 at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > > -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20170518/2ea5dc20/attachment-0008.html>