----- Original Message ----- > Excerpts from Stephen John Smoogen's message of 2015-01-09 10:25 +10:00: > > On 8 January 2015 at 17:01, Dan Callaghan <dcall...@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...)
I was experimenting with dynamic subpackage generation, but you need Lua for that. And while it can be done, it's actually much uglier than the way I proposed. I guess the only nice way would be to add support for dynamic subpackage generation to RPM directly. That is actually something I've wanted to propose for some time now, but didn't really get to it... Also, it's questionable that it'd get to RHEL 7 rpm, so I think we're stuck with this. > -- > Dan Callaghan <dcall...@redhat.com> > Software Engineer, Hosted & Shared Services > Red Hat, Inc. -- Regards, Slavek Kabrda _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
