EPEL Python 3 for 7?

[Dave Peterson]

Wouldn't this be a perfect use case for Software Collections?

http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Software_Collections_Guide/index.html

-Dave




On Thu, Jan 16, 2014 at 7:32 AM, Dave Johansen <davejohansen at gmail.com>wrote:

> On Thu, Jan 16, 2014 at 8:03 AM, Toshio Kuratomi <a.badger at gmail.com>wrote:
>
>
>> On Jan 16, 2014 1:08 AM, "Matthias Runge" <mrunge at matthias-runge.de>
>> wrote:
>> >
>> > On 01/15/2014 04:32 PM, Stephen Gallagher wrote:
>> >
>> > >
>> > > So my suggestion would be that EPEL should have two branches for EPEL
>> > > 7: the epel7 branch and the epel7-pending branch. The idea of this
>> > > second branch would be sort of an EPEL Rawhide, where major upgrades
>> > > can be staged. Then, when RHEL releases a minor update (such as RHEL
>> > > 7.1), we have a (one-month?) integration period where we ensure that
>> > > packages in epel7-pending work on the newest minor release and then
>> > > they are merged back to epel7. If they miss this merge window, they
>> > > have to wait until the next minor release.
>> > >
>> > > This allows us a regular, planned ability to move to newer EPEL
>> > > packages, without destabilizing EPEL in general.
>> > >
>> > > In order to not make this a willy-nilly breakage every six months, we
>> > > might want to set some limits (or at least guidelines) on what is or
>> > > is not allowed to upgrade at the minor release. But I'd be fine with
>> > > deferring making such decisions until we have a demonstrated need
>> > > (i.e. fix it only if packages/EPEL is actually breaking).
>> > Interesting idea, I like that.
>> >
>> > This would be a place to put e.g django-1.6.
>> >
>> Although I would favor being able to deprecate one version of a package
>> and introduce a newer incompatible version in some manner I have to point
>> out here that if we "set some limits" to avoid breaking things then those
>> limits would almost certainly cover frameworks and language stacks like
>> python and django.
>>
>> This is the basic problem that we inevitably face - people who have
>> deployed software that relies on the old version inevitably do not want a
>> new, incompatible version to appear in the reps that causes them to have to
>> do extra porting work.  People who have not yet deployed (or written) their
>> software want the latest and greatest version of the software so they can
>> build it using features provided by the latest version.
>>
>> I think there's two classes of upgrade policy that we might implement to
>> address this.
>>
>> 1) we think we have enough manpower in epel to support more packages.  If
>> this is the case then we should be looking at ways to support more than one
>> version of packages on the repository.  Ideas here include:
>>
>> + parallel versions (what we do today.  Parallel installable Python3.3
>> and python3.4 packages are in this vein).
>>
>> + multiple versions that have explicit conflicts between them.  Conflicts
>> aren't allowed in fedora packages but this could be an epel difference.
>>
>> 2) we don't feel we have the manpower to support multiple versions.  In
>> this case we have to decide whether we are more strongly in favor of
>> supporting existing deployments or supporting new deployments.  Existing
>> deployments is our default now.  Our story for new deployments is that we
>> must have parallel installable versions to make that use case work.
>> Sgallagh's proposal turns that around so that we favour new deployments'
>> needs more than existing ones.  There are ways to improve it for existing
>> deployments - for instance we could create a new repository for each of
>> these point releases. Those repositories could be open or closed for new
>> packages/updates depending on how much manpower we think we have to throw
>> at the problem.
>>
>
> My personal vote would be for either the parallel versions of #1 so people
> aren't forced to upgrade or #2 with maintaining the priority for existing
> deployments. EL provides a known/stable base and I think that EPEL should
> maintain that same philosophy for at least the frameworks and language
> stacks.
>
> _______________________________________________
> epel-devel mailing list
> epel-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/epel-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20140116/a4a98932/attachment-0001.html>