On 11 September 2014 08:41, Bohuslav Kabrda <bkabrda(a)redhat.com> wrote:
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.
Possible solution:
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.
Proposed implementation:
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 EPEL-6.7.
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)
python35-beautifulsoup4-4.3.2-1.el7.noarch
python35-bunch-1.0.1-4.el7.noarch
python35-chardet-2.0.1-7.el7.noarch
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!
Slavek
--
Stephen J Smoogen.
_______________________________________________
epel-devel mailing list
epel-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
--
Stephen J Smoogen.