>>> So it's been discussed a little about doing a EPEL bootstrap for new
>>> architectures. We have a number of arches wanting to do this (ppc64le,
>>> aarch64, i686, s390x). So ppc64le will be our first and this is an
>>> overview of the process I'll be using to do it. Once it's complete
>>> I'll do a better write up as I suspect some things will evolve as we
>>> go on down the path.
>>>
>>> So the general overview of the process is:
>>>
>>> 1) add new builders to koji (ppc64le complete)
>>> 2) create separate inherited build target and tag
>>> (epel7-archbootstrap) with associated architecture
>>> 3) run scratch builds in that target using the git commit hashes from
>>> the latest builds in the epel7, epel7-testing and epel7-candidate tags
>>> 4) For each scratch build completed, run mergeScratch(task_id)
>>> 5) when all builds are complete enable the arch on the main epel7
>>> target
>>> 6) sign all new packages
>>> 7) update bodhi, pkgdb, mash configs
>>> 7) mirror out
>>>
>>> I have some scripts to do the above which I'll publish for reference
>>> once I've cleaned them up a little.
>>>
>>> This process isn't perfect. The new arch builds may not have the exact
>>> same build dependency NVRs because, at least in the case of ppc64le,
>>> the first EL7 release with .el7 distags is 7.2 and obviously most of
>>> epel7 is built against < 7.2. The mergeScratch koji API call imports
>>> all the build logs which helps mitigate this from a debug PoV. There's
>>> not really a good way to deal with this, and obviously once the new
>>> arch is enabled they'll be the same moving forward. I don't see it as
>>> an issue really, just making note of it here for reference.
>>>
>>> Looking at the current stable epel7 builds, as of a couple of days
>>> ago, we have around 4763 source packages, of which 2686 are noarch
>>> (and hence don't need to be rebuilt) and a touch under 2077 (2077 at
>>> time of check) are arch dependent.
>>>
>>> Let me know of any queries, questions, concerns etc
>>
>> sounds sane :-) But how will be handled packages that require some
>> boostrapping procedure - is a new combo of boostrap and final build
>> required in existing EPEL (dist-git) or or will be the bootstrap build
>> taken from the original EPEL bootstrap (built eg. against RHEL-7 Beta)
>> and the current latest NVR will be then the final build?
>>
> Note that I have packages already built in my local ppc64le epel7
> environment and
> some could be used to help in bootstrap.

Sorry, that's not going to happen, but if you've got a list of package
sets that need specific bootstrapping that would be useful.

Peter
_______________________________________________
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Reply via email to