Excerpts from Stephen John Smoogen's message of 2015-01-09 10:25 +10:00:
On 8 January 2015 at 17:01, Dan Callaghan <dcallagh(a)redhat.com>
wrote:
> Personally I am not looking forward to maintaining more branches
> and/or (sub-)packages for every python3X-*.
>
I need to understand what you mean here? Even in EPIC and SCL's there would
have to be some overlap and multiple branches over time due to the fact
that python, ruby, java, etc all have multiple subpackages which would need
to be built for multiple releases. They may not be for a long lenght of
time, but the work is not going away.
Right, even for Fedora there are multiple branches of course, what
I meant was multiple *divergent* branches.
For all my packages I prefer to keep a single spec for all branches with
conditionals when necessary. Most of my packages are fairly stable and
not releasing new incompatible versions too often, so most of the time
I can just do one update and then all branches are a git fast-forward.
The only time I have divergent branches is when a stable release needs
a bug fix but rawhide has already moved to a newer incompatible version.
That's fairly rare for my packages.
So that approach works fine right now because we just have python-foo
and python3-foo subpackages and they can just keep rolling through as
new releases are branched and old releases die off.
What I was picturing for EPEL Python 3 was that I would have to rename
the subpackage to python34-foo. Then every time Python 3 is bumped
I would have to rename all the subpackages to python35-foo, and then
I would have divergent branches for as long as both 3.4 and 3.5 still
exist. That's the situation I was complaining about.
A much better approach is what Bohuslav has come up with, a single spec
that builds both python3X and python3X+1 subpackages. And we can script
the mass version bumping as well. So that addresses my worries.
(The example spec makes me a bit sad with how complex and repetitive it
is, but I guess there is nothing really we can do about that...)
--
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Hosted & Shared Services
Red Hat, Inc.