[EPEL-devel] Re: [POC-change] Fedora packages point of contact updates
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 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Django in EPEL6
On 03/09/2016 11:39 AM, Stephen John Smoogen wrote: > On 9 March 2016 at 02:58, Matthias Runge 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
[EPEL-devel] Re: Django stable RPMs
I believe the future of Django in EPEL is a topic that is being discussed on the EPSCO meetings last week and this week (18:00 UTC on Wednesdays in #fedora-meeting, iirc). I'm hoping that even if a newer, 1.8 based Django package is added to EPEL6, that the existing one named Django14 can be kept for legacy usage. The Django14 package having that unconventional name would allow a new package to use the more conventional python-django name which is convenient. On Tue, Nov 8, 2016 at 7:05 AM, Stephen Finucane wrote: > Afternoon, > > I'm currently working through the final stages of a new release for > Patchwork [1]. One of the things that's been discussed extensively in the > past is the versions of Django we support. Most sysadmins refuse to use > packages outside of those provided by their distro (i.e. no pip). After a > long discussion about this time last year [2], we resigned ourselves to > having to support the deprecated Django 1.6 and 1.7 releases as these are > the most recent version available in EPEL and Debian Stable, respectively. > However, the next version of Patchwork introduces a new dependency - Django > REST Framework - which is technically avoidable but really should be used. > This dependency is available in Debian Testing, but I see no recent version > of package in EPEL, sadly. > > I looked into packaging DRF, but it seems EPEL doesn't support a modern > version of Django. I realize there's been a lot of discussion on this in > the past [3][4][5], but I couldn't find any conclusion. As such, I have a > question: what would it take to start packaging the *stable* versions of > Django (currently 1.8)? Django publishes a timeline for stable vs. > non-stable packages, which includes some overlap between the last stable > release and the next one, a la Ubuntu [6]. This seems compatible with > EPEL's packaging strategies, thus, I imagine it should be possible to > package stable versions. When a stable package is deprecated upstream, we > could remove from EPEL as expected. Any package that doesn't upgrade to > support the latest stable version is probably dead and not worth retaining > in EPEL, with some exceptions (Reviewboard). > > I realise that, for better or worse, Django 1.6 must be kept (ReviewBoard, > for example, is stuck with 1.6 for the foreseeable future [7]). This would > probably mean we'd need to create a versioned Django package > (python2-django18, python3-django18). However, I'd be willing to help with > both this and a DRF package as long as I continue to contribute to and > maintain Patchwork (it's been two years and I'm not quitting any time soon). > > Is this something that we could put together a game plan on? > > Cheers, > Stephen > > [1] https://github.com/getpatchwork/patchwork > [2] https://lists.ozlabs.org/pipermail/patchwork/2015-November/002046.html > [3] https://lists.fedoraproject.org/archives/list/epel-devel@lis > ts.fedoraproject.org/thread/RKG34VEBSKXPKQLZB4H2AH7PPEA4RJV3 > /#7I6KXRTG7ONPURZ3RZH67E2JQXQHOYO4 > [4] https://lists.fedoraproject.org/archives/list/epel-devel@lis > ts.fedoraproject.org/thread/B6ASOXHXX4SLUDE3WOR2GFFRDEAJX436 > /#A22LLWB5QM3PLEWN7PMFVRK3WCM3RTIJ > [5] https://lists.fedoraproject.org/archives/list/epel-devel@lis > ts.fedoraproject.org/thread/CBCLW2VUMZY2AXBBRMLPTKIWIYZRJMV2 > /#FIGALSOZALNNOY42DHNSNPB5BSGWSXRA > [6] https://www.djangoproject.com/download/ > [7] http://blog.beanbaginc.com/2015/09/11/work-toward-a-django- > 1-8-port-for-review-board/ > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
