On Thu, Jan 16, 2014 at 04:47:04PM -0800, Dave Peterson wrote: > > 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 > I was considering this earlier and I'm a bit conflicted about that. There's several problems with this. The most obvious is that SCLs are rather coarse grained and we want to solve this for both the coarse grained stuff like (python interpreter) and fine grained things (like upgrading a single library)
The second problem is that we don't just want these things for users to use. We also want them for our own use. But SCLs are meant to be isolated from the 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. -Toshio > -Dave > > > > > On Thu, Jan 16, 2014 at 7:32 AM, Dave Johansen <[email protected]> wrote: > > On Thu, Jan 16, 2014 at 8:03 AM, Toshio Kuratomi <[email protected]> > wrote: > > > > On Jan 16, 2014 1:08 AM, "Matthias Runge" <[email protected]> > 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 > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/epel-devel > > > > _______________________________________________ > epel-devel mailing list > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/epel-devel
pgpbode0665Qq.pgp
Description: PGP signature
_______________________________________________ epel-devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/epel-devel
