I like Stephen's idea. That is how we handle python 3 packages in the IUS repo.
To avoid conflicts/confusion with SCL or EPEL packages, all future IUS packages will be
suffixed with a u (such as python34u). Currently our python3* packages all conflict with
each other. We have an open request to allow multiple version of our python3* packages by
using update-alternatives . We may or may not implement it, but it is another option
that the EPEL might want to consider.
- Carl George
[epel-devel-bounces(a)lists.fedoraproject.org] on behalf of Stephen John Smoogen
Sent: Thursday, September 11, 2014 02:31 PM
To: EPEL Development List
Subject: Re: EPEL EpSCO Email Meeting:
On 11 September 2014 08:41, Bohuslav Kabrda
Problem trying to be solved:
EPEL's original goal around a 5-7 year product has run into issues where various
packages end up having shorter lifetimes than can be maintained in that period. What
happens is that the upstream is changing the code too massively for any sort of
'back-port' to be possible. Some software can be 'patched' around by
making it parallel installable but others (say puppet) only work if there is only one
version not just on the system but throughout an entire ecosystem of systems (thus if you
update one, they all have to be updated to the same version.) While EPEL has a process of
saying you can announce a major change it is severely frowned on and usually ends up with
various users asking 'can you just keep the older version around a bit longer...'
ad infinitum. Another problem is that it isn't clear how much notice is needed for a
change to be made or what changes are being made so that users and package owners end up
confused and upset with each other.
Make it so that updates to these sorts of packages occur at regular intervals. There are
three cycles these could occur: regular date driven (July 1st of every year for example),
the Fedora release cycle (Fedora 22 has been released, you can update now), and the Red
Hat Enterprise release cycle (RHEL-6.6 is out, you can release now). Each of these cycles
has their bonuses and minuses but I think that connecting to the RHEL cycle will be more
in line with what downstream users of EPEL are going to be more in sync with.
Every Red Hat Enterprise Dot Release has a beta period and then a release period. After
the release period there is a couple of weeks until a CentOS release is available. Since
only the betas and CentOS release are generally available to any person off the street I
am looking at those being 'action points' where the dot release period would be
done. When a RHEL beta dot release (example RHEL-6.6 beta) is announced, EPEL.dot would
say that packages to be updated in the next release are going to be accepted into
EPEL-dot-testing. Package owners who are needing or wanting to make major changes in their
EPEL package sets would target builds to that channel. People can test as needed or at
least be aware where they could have tested. Sometime after the next dot release, CentOS
releases their latest 'this is the state of CentOS build' which anyone needing to
test latest builds can get. This acts as a marker for when EPEL.dot will 'release'
its next tree which would be 1 month after the CentOS GA. During that time, everything is
rebuilt against the latest RHEL (to find any FTBS or ooops they dropped libmuffin and I
needed it) and at the end of the month EPEL-6.7 is put out and EPEL-6.6 is set to be sent
to archives after an appropriate time. Like CentOS, EPEL-6 -> EPEL-6.6 and then
In the case of last planned release (RHEL-5.12?), a different mechanism could be used for
when updates occur if there is enough people willing to do the work. Otherwise packages go
into that tree until EPEL ends building for it.
Note only one tree is being built against. If someone wants to 'keep' EPEL-6.5
running, they can grab the src.rpms from archives and do it themselves on their own
hardware.. EPEL only deals with RHEL current.
Have I made this clearer or muddier?
Thanks for starting this initiative and sorry for my late response. Anyway, my 2 cents:
As maintainer of python3 in Fedora, I've already been asked by quite a lot of people
to put python3 in EPEL 7. Most notably by DNF maintainer and people from Fedora
Infrastructure. My problem with doing this is, that I want to able to actually update
python3 point releases (e.g. from 3.4 to 3.5) at some points during EPEL 7 life. So
I'm trying to understand how this proposal would help me. Here are my notes and
thoughts on the situtation with python3 and the possible solution:
- Generally, python3 point releases can't be safely considered backwards compatible
and all depending packages need to be rebuilt.
- The above point I think makes updating python3 go against current EPEL policies. If I
wanted to do it "right", I would need to start with python34, then after some
time add python35, python36 etc. (for each of these, I'd need to keep the whole stack
of dependent libraries, which brings even more iffy problems, like "where should
these packages be at dist-git", "should these conflict or be installable in
parallel", "when/how do we obsolete the old versions", ...)
- So I'm wondering whether we could have just "python3" and
("python3-*" extension modules and other dependent packages). The
"python3" package itself would be updated at time of RHEL point releases,
assuming a new minor version has been released prior to the update period (RHEL beta).
- Now, I'm not sure how this should work with extension modules and other packages
depending on python3. Would it make sense for them to live in the main repo, assuming
they'd depend on a package that lives in the "EPEL-dot" repo? I think not,
but this would basically cause all python3 depending packages to live in
"EPEL-dot". I'm not sure whether that is a problem or not. It doesn't
feel exactly right, but I guess it's the right thing to do...
- So basically the whole python3 stack would need to be rebuilt together during the RHEL
beta period, which might be very short, considering that we may be talking about hundreds
of packages with dependency cycles etc. In case that the rebuild wouldn't be completed
on time, I think it should be safe to just wait for the next RHEL dot release.
So I believe that various python consumers have wanted to have seperate python trees that
are subversion specific as they can move to a newer release when they wanted to or keep
parallel versions around. So what I would like to do is generate the least amount of
surprise for them (versus no surprise).
Here is my suggestion:
1) Make python34 currently python35 later and python36 later..
2) The expectation will not be putting python35 out as soon as it comes out. As you state,
modules and such may need to be ported to the newest version etc so we need a baking
period before the next version is ready for EPEL (so if python35 were in Fedora 23, then
when Fedora 24 came out it would be time for putting it in EPEL.)
3) Make all submodules versioned like the parent (pulling 3 python packages installed on
my system as an example)
Name space them appropriately in their directory space.
4) Keep the old python3 version around for a release cycle if possible. If not then it
goes away when python35 replaces python34 in the 'release cycle'.
A different solution would be to try and work out a method similar to what I was told
Debian uses where something like a %post helper 'recompiles' the base helper in
say python-bunch for whatever versions of python are installed on the system and places
those .pyc over in the appropriate trees. That seems more error prone though in case of
python which relies on C code etc.
To answer your further question, I expect that EPEL.dot will only be allowed to depend on
EPEL and EPEL would not be allowed to depend on EPEL.dot. So if python35 is in EPEL.dot
then python3x-bunch will be in EPEL.dot.
I am saying it this way as you could end up with problems where python application built
against python-3.4 may not work without changes to the code in python-3.5 and would break
horribly if it just relies on python3 as its dependson or something similar. [Having
fought this over and over again with changes from python24 -> python25 etc etc.
Does this make sense? Comments/suggestions?
Thanks a lot!
Stephen J Smoogen.
epel-devel mailing list
Stephen J Smoogen.