[scl.org] RPM list builder & RHSCL rebuild recipes

Nick Coghlan ncoghlan at redhat.com
Mon Jul 17 05:00:15 UTC 2017


On Sat, Jul 15, 2017 at 1:12 AM, Davis, Daniel (NIH/NLM) [C]
<daniel.davis at nih.gov> wrote:
> It might be nice to provide an sclo-python35 and sclo-python36 so that users such as we have an easier time not updating.

Aye, I think that would be sensible, even though it's not something
I'd personally want to work on in my own time.

However, I think the most suitable model would be something similar to
the way the community addons for PHP work, where the rh-pythonXY
packages are still used as a base, with community managed addon
streams being built around those, similar to the community addons for
PHP that Remi publishes.

That is, the way I'd see that working in terms of the way the
underlying distros work:

- sclo-python: Fedora equivalent (community defined)
- rh-pythonXY (in RHSCL): RHEL equivalent (Red Hat defined)
- rh-pythonXY (from SCLo): CentOS equivalent (still Red Hat defined)
- sclo-pythonXY: EPEL equivalent (community defined)

That approach *does* leave open the question around Red Hat's security
policy for rh-pythonXY updates (which is currently backport-based, the
same as RHEL, with rebasing to new upstream maintenance releases being
the exception rather than the rule), but sclo-python will be able to
fill the "always rebase" role for 3.6 until 3.7 comes out, which means
we can postpone coming up with a different answer until we get closer
to having an upstream 3.7.0 release to worry about (and even there we
have options - we may decide that sclo-python shouldn't update until
after 3.7.1 is out, for example).

>   I hope we will not for a long time be in the situation between python 2.7 and python 3, but it could happen between 36 and 37 for any of a number of reasons.   However, that implies more work to get it set up.    It becomes non-automated as 37 comes out.

Yep, which is why I think we're going to need Red Hat's paid
maintenance staff somewhere in the sustaining engineering path for the
stable versions, similar to the way that CentOS is a RHEL rebuild that
Fedora's EPEL can build on top of. That kind of work makes for a
decent job, but a fairly lousy volunteer activity :)

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Platform Engineering, Brisbane




More information about the SCLorg mailing list