EPEL Python 3 for 7?

[Toshio Kuratomi]

On Fri, Jan 17, 2014 at 10:55:09AM -0500, Matthew Miller wrote:
> On Fri, Jan 17, 2014 at 08:05:23AM -0700, Dave Johansen wrote:
> > > system.so we've mostly decided that things in the system shouldn't use SCLs
> > > to work.  So we still need to solve the problem of newer python interpreter
> > > and newer django framework for use with apps that EPEL ships.
> > What about having a separate EPEL repo for SCLs and/or these newest version
> > of things? Like you mentioned before, this takes more work, but if then
> > those that want the stable base can have it and those that want the newest
> > can have it as well.
> 
The problem I'm raising is that SCLs don't solve the problem that sgallagh
is wanting to address by current policy.  He has applications (ReviewBoard)
that need newer versions of a framework (django) in order to run.  For us to
ship reviewboard in EPEL, we'd need to figure out if we want to allow that
and how.  Possible options are:

* ReviewBoard is in its own SCL.  The SCL deps on the appropriate django SCL.
* ReviewBoard is not in an SCL and we allow mainstream packages to dep on
  SCLs.  We need to figure out guidance on how a package can enable an scl
  for its own use as well.

Either of these may exacerbate the problem of an enabled scl polluting other
applications (especially hard if we get into invoking other processes from
that application... env variables like LD_LIBRRY_PATH will probably get
passed onto the invoked process).

> Or possibly an additional sub-project separate from EPEL. The idea has been
> kicked around a little bit -- Robyn Bergeron calls it "EPIC" (for Extra
> Packages for Infrastructure and Clouds, I think). I was thinking about this
> more recently in the context of "things we need for Fedora.next in the
> coming year or so". The new repo might target both EL and Fedora and provide
> alternative versions maintained on, say, a 3-year lifecycle.
> 
Yeah -- I think that something like this could be good.  A repo with
a 3 year lifecycle may make sense for RHEL more than Fedora as the
basesystem we're building on is still active at the end of that period.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20140117/ac1fab9a/attachment.sig>