[Pulp-dev] Upcoming epel6 Dependency Issues

Wed Nov 9 13:19:42 UTC 2016

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 <bbouters at redhat.com> 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 <ipanova at redhat.com> 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" <mhrivnak at redhat.com>
>> To: "Brian Bouterse" <bbouters at redhat.com>
>> Cc: pulp-dev at redhat.com
>> 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 < bbouters at redhat.com >
>> 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 < mhrivnak at redhat.com >
>> wrote:
>>
>>
>>
>>
>>
>> On Wed, Nov 2, 2016 at 3:10 PM, Brian Bouterse < bbouters at redhat.com >
>> 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
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>

-- 
Elyézer Rezende
Senior Quality Engineer
irc: elyezer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20161109/175a6b74/attachment.htm>