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 <davejohansen(a)gmail.com> wrote:
On Thu, Jan 16, 2014 at 8:03 AM, Toshio Kuratomi <a.badger(a)gmail.com>
wrote:
On Jan 16, 2014 1:08 AM, "Matthias Runge"
<mrunge(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
_______________________________________________
epel-devel mailing list
epel-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel