Excerpts from Stephen John Smoogen's message of 2015-01-09 10:25 +10:00: > On 8 January 2015 at 17:01, Dan Callaghan <[email protected]> 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 <[email protected]> Software Engineer, Hosted & Shared Services Red Hat, Inc.
signature.asc
Description: PGP signature
_______________________________________________ epel-devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/epel-devel
