How adopt option 3 will affect some of our customers? I mean there are projects, like Katello and Satellite, that rely on Pulp to deliver their functionality even on RHEL6.
Even though I really like the idea on dropping RHEL6 I want to make sure we don't just break thinks for our users. On Tue, Nov 8, 2016 at 1:34 PM, Brian Bouterse <[email protected]> wrote: > +1 to option 3. > > Also I'm voicing to EPSCO that they should keep the Django14 around for > "legacy" purposes. I've been e-mailing on epel-devel to that end too. We'll > see what the sunset plan is for that at the next EPSCO meeting tomorrow. > > > On Tue, Nov 8, 2016 at 5:37 AM, Ina Panova <[email protected]> wrote: > >> +1 to option 3 >> >> -------- >> Regards, >> >> Ina Panova >> Software Engineer| Pulp| Red Hat Inc. >> >> "Do not go where the path may lead, >> go instead where there is no path and leave a trail." >> >> >> ----- Original Message ----- >> From: "Michael Hrivnak" <[email protected]> >> To: "Brian Bouterse" <[email protected]> >> Cc: [email protected] >> Sent: Monday, November 7, 2016 9:32:08 PM >> Subject: Re: [Pulp-dev] Upcoming epel6 Dependency Issues >> >> Thanks for the clarification. If they do end up removing Django14 from >> epel6, I think we have these options: >> >> 1) Provide a django package ourselves. No supported django release runs >> on python 2.6, so we would be providing an unsupported version. >> 2) Show users how to install django some other way. Either by retrieving >> the Django14 package direct from the build system, or via pip, or something >> else. It's clear in this case that the user is taking responsibility for >> installing an old and unsupported version of django, and they must be >> vigilant. It's the price for running pulp on el6. >> 3) Stop supporting el6. This might be the nail in the coffin. It's >> getting harder all the time to provide supported dependencies on el6, and >> el7 has been out for a while now. If the platform removes one of our >> biggest dependencies, there's only so much effort we should reasonably go >> to as an upstream to keep it working. >> >> Thoughts? Preferences? I lean toward option 3 but could be persuaded. >> >> Michael >> >> On Wed, Nov 2, 2016 at 4:18 PM, Brian Bouterse < [email protected] > >> wrote: >> >> >> >> That date was all wrong. The real date is Wednesday 11/9 at 18:00 UTC in >> #fedora-meeting on freenode. >> >> Yes they would add python34 to epel6, then add Django 1.8 package that >> only runs on Python 3.4. Since there are a lot of cve's against Django14 >> they seemed inclined to remove it soon. Packages being incompatible with >> the 3.4 runtime would have to handle that themselves. As you point out, >> once Django14 is removed, anything Pulp 2.6+ would break. >> >> We should try to get them to leave Django14 in the repo for as long as >> possible. It's called Django14 and the new one would be python-django I >> believe, so there shouldn't be an issue with them both being offered in >> epel6. >> >> >> >> On Wed, Nov 2, 2016 at 3:35 PM, Michael Hrivnak < [email protected] > >> wrote: >> >> >> >> >> >> On Wed, Nov 2, 2016 at 3:10 PM, Brian Bouterse < [email protected] > >> wrote: >> >> >> >> It seems that the mongodb and Django14 packages in EPEL6 are going to be >> changing in some big ways. It's still early in the conversation, but here >> is what I've learned at the EPSCO (EPel Steering COmmitee) meeting today[0]. >> >> mongodb 2.4 is not supported upstream from epel and EPSCO approved an >> upgrade of mongodb in epel6. It will likely be to a 3.x based version. It >> will first be pushed to epel-testing first. What is the newest mongodb that >> we are compatible with? do we know? >> >> One idea I have is to create pulp-smash test jobs which are testing pulp >> using bits from epel-testing in addition to epel-release. That will help us >> identify issues before one day it just breaks on us. >> >> Also, Django14 is on the short list to be pulled from epel6 due to >> upstream not supporting it and is unmaintained from a cve perspective. >> Everyone recognizes now that it must be replaced with something versus what >> happened last time of having it just removed. The current thinking is to >> add python34 (not scl) to epel6 and add python-django 1.8 to epel6 also. >> The will be discussed again at the EPSCO meeting next week on Thursday 11/2 >> at 18:00 UTC in #fedora-meeting on freenode. I'm planning to attend, but >> come if you're interested. >> >> One or more parts of the date/time can't be right. Can you double-check? >> >> >> >> >> This still isn't great for Pulp 2.y on EL6. Pulp will break when Django14 >> is removed, even if Django 1.8 is available because Pulp 2.y and all of its >> deps would have to be updated to run in the Python 3.4 runtime. I believe >> this will likely happen before Pulp 3 is even released. I don't think we're >> going to switch the EL6 runtime to Python 3.4 for Pulp 2.y, so we need to >> think carefully about our options here. >> >> Are you saying they would add python34 to epel6, then add a django 1.8 >> package that only runs on python 3.4? I suppose that would make some sense >> since django 1.8 dropped support for python 2.6. But it wouldn't be much >> help for pulp 2.y. >> >> >> >> _______________________________________________ >> Pulp-dev mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > > -- Elyézer Rezende Senior Quality Engineer irc: elyezer
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
