[CentOS-devel] CentOS 7 extras for alternative arches and Koji workflow.

Sandro Bonazzola sbonazzo at redhat.com
Thu May 18 15:52:30 UTC 2017


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


More information about the CentOS-devel mailing list