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 <[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
