On 03/09/2016 11:39 AM, Stephen John Smoogen wrote: > On 9 March 2016 at 02:58, Matthias Runge <mru...@matthias-runge.de> wrote: >> On 08/03/16 18:55, Orion Poplawski wrote: >>> On 03/08/2016 10:42 AM, Brian Bouterse wrote: >>>> This removal has been problematic for a lot of software including >>>> the listed EPEL dependencies and anything those depend on. I >>>> propose the following be done: >>>> >>>> - Temporarily un-retire Django14 in EPEL6, and allow a planned >>>> sunset after some period of time. It would not receive updates >>>> during this time since upstream Django deprecated it already. >>>> >>>> - Add python-django[0] from EPEL7 (python-django-1.6.11-5.el7) to >>>> EPEL6 in a way that has allows some time overlap with Django14 >>>> being also available. During that time other packages can switch to >>>> using python-django gracefully. This should be feasible because >>>> Django 1.6 is the last Django Y release which will run on Python >>>> 2.6 making it feasible to run on EL6. >>>> >>>> Other ideas or suggestions are welcome. >>>> >>>> [0]: >>>> https://admin.fedoraproject.org/pkgdb/package/rpms/python-django/ >>>> >>>> -Brian >>> >>> With the relatively fast moving nature of django, I'm wondering if >>> any django package in EPEL should be unversioned. It seems like we >>> should have python-djangoXX instead. Although I have no idea how >>> easy it is to implement that. >>> >>> Also, while Matthias has issued an update recently for 1.6 in EPEL7, >>> it looks like its days are numbered as upstream has dropped it as >>> well: https://www.djangoproject.com/download/ >>> >>> Hopefully Matthias will chime in with his thoughts. >>> >> >> Hello, >> >> I'm very sorry about this, and I should have communicated at all. >> >> Upstream django releases about every 9 months a new release, they're >> announcing deprecations as soon as they know in advance, leaving enough >> time to adapt. Unfortunately, there are downstreams struggling with the >> speed of development. >> >> So, matter of fact is, Django version 1.4 was the last LTS version being >> able to run on python-2.6. >> >> I had to make a cut here, since there were discovered 4 security issues >> in later django versions. Django-1.4.x was out of support by upstream >> already, thus, nobody really looked at that, if it's vulnerable. >> >> I wouldn't really consider Django-1.6 to be an alternative here, that >> was being deprecated around 9 months before Django-1.4. I may be >> stopping support on Django-1.6 in the near future. For epel7, the better >> candidate for LTS is Django-1.8. >> >> Speaking of python-djangoxx: I have been there, it's a pain as well. And >> that will eventually let the packet space explode, i.e you would have to >> have something like python26-django14-tagging (or whatever). >> >> Situation is not ideal anyways. >> >> My proposal would be, to un-retire Django14 for EPEL6. >> >> Looking at the long list of (now broken) dependencies, I would expect >> lots of leaf packages, living there because someone thought it'd be nice >> to have it. But, in fact, one should seriously think to retire those >> packages. > > > OK from what I can tell, we are going to need a python27 for EL6 (and > possibly EL5). Can the groups that need django and other later python > toolkits help out on the work required to do this?
+1 to your suggestion. The ideal situation would be to have python27 made available for EL6, which would allow the current Django LTS 1.8 to be made available in EPEL6. What goes into that effort-wise? I don't know, but I agree its the best option for a long-term resolution of this issue. Another option is to build the Django LTS python-django-1.8 against software collections (SCL), but that will be very problematic since it's a framework. As I understand it, any other dependency which would run inside Django would also have to be built against SCL. It's an option but not a viable one in my opinion. A last option would be for some saint of a person to evaluate and backport every security fix from current Django versions to 1.4 or 1.6 which could allow it to run on python26. I also don't think this is viable or even responsible. _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
