'policy' for multiple versions of same software in EPEL

[Greg Swift]

On Thu, Oct 18, 2012 at 10:38 AM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> On Wed, Oct 17, 2012 at 12:57:31PM -0500, Greg Swift wrote:
>> > ...snip...
>> >
>> >> > Right. I think this may be something we want to ask the Fedora
>> >> > Packaging folks (who live on the packaging list) about.
>> >>
>> >> good plan
>> >
>> > Can you post over there about this and look for feedback?
>>
>> I am going to.  my procrastination excuse was that I was hoping to
>> hear from at least one more person before I did in case there was more
>> feedback.
>>
> There are quite a few reasons to avoid Conflicts.  Some of them are listed
> on the Conflicts wiki page but there are others as well.  For instance, in
> Fedora, we need to make the effort to be porting software forward to newer
> versions of their dependencies rather than maintaining extra packages for
> backwards compatibility.  But EPEL doesn't need to play by the same rules if
> they don't want to.

Ya.  That's where it gets interesting.  I completely agree with all of
the points towards Fedora, but EPEL is definitely a different beast.
Its that weird limbo between rolling release and very long term
support but not being paid to care about it. (Although I guess most
contributors are kinda paid because they are likely doing it for their
dayjob, but that likely rarely includes caring about other people's
long term needs).

The EPEL philosophy provides a basic set of guidelines.
http://fedoraproject.org/wiki/History_and_Philosophy_of_EPEL#Philosophy

1: Never replace or interfere with RHEL packages
2: Packages should be supported for the life of related RHEL project
3: No manual update process or procedures
4: During 'stable' EPEL cycle package shouldn't update in a way that
changes user experience or does more than just bugfixes.

A few thoughts on these:

1: That has become complicated.. i know there is a very long thread
about the scenario where Red Hat buys and commercializes a tool that
was already in EPEL.
2: Nice concept, and we can keep them around but 'supported' depends
on your definition... see below
3: This is great for 'no suprises' but what about the people where an
upgrade is not a surprise?
4: Makes sense.

Seems to me that how people seem to want to use EPEL should also be
considered.  I just watched one of the PuppetConf presentations while
I was writing this and heard something along the lines of 'use FPM
because getting up to date software in something like EPEL is too
hard'.  How does that help when the only thing stopping that new
version being available is a poor upgrade path for the software in
packaging policy (including recommended methods)?

> There's a basic question of cost and benefit.  For Fedora, with its shorter
> time to EOL, the costs of a no-Conflicts policy are less than in EPEL where
> your base platform is going to be available for years.  Just bear in mind
> that you're going to be maintaining those compat packages for years as well.
> So the costs of allowing Conflicts are also higher.

The cost of maintaining the compat packages can be huge, but the
reality is that for most of the ones we are talking about replacing
the likelyhood of an update diminishes every month as most of the new
packages are for software that has been/will be left in dust by
upstream.  If there is a valid upstream release for security reasons,
that older package can still be updated.

Some examples of last update dates from upstream for existing packages in EPEL:
rspec             1.3 - Apr 2011
collectd          4 - Mar 2011
django           1.3 - Oct 2012 (security update, 1.4 is current stable branch)
zabbix            1.6 (rhel5) - Mar 2010
zabbix            1.8 (rhel6) - Aug 2012 (likely last non-security
update, 2.0 branch is current stable branch)
bugzilla          3.4 - Feb 2012 (security update, branch has since closed)
mediawiki116 1.16 - May 2011 (1.17 release was discontinued Jun 2012)
mediawiki119 1.19 - Sep 2012 (based on current average release cycle I
give this until mid-2013)

The mediawiki are the only ones that are named including the version.
I didn't want to browse the entire list of packages, so these are just
the ones that popped out at me.

The ones that are within the 2012 year don't seem to bad right now.
But what about in 2017 (rhel5) or 2020 (rhel6) when non-extended
lifecycle of that release ends?

> For your two initial examples, I think that you'd want to be careful about
> allowing conflicts but might be able to justify it in one of the cases.  You
> need to ask yourself: "Would any user want to install both versions of this
> package at the same time?"  For an application, this may be no.  For
> a library, this is almost always going to be yes.  To me that rules
> rubygem-rspec right out as a good case for Conflicts.  Collectd is also
> libraries but the case could be made that they'd be coupled to whatever
> version of collectd is running on the system.  So you might be able to make
> the case there.  (But do think about things like -- what if a user has some
> boxes running collectd5 and others collectd4.  If these libraries were
> parallel installable would they enable the user to query information from
> both sets of boxes?)

So... I agree with the concept of compat packages.  Except when it
requires the package maintainer to patch the code (aren't we against
non-upstream accepted patches?) and create a non-standard installation
of the software.  In ruby (or python, or perl), if anyone that wants
to package or deploy software that uses the newer version has to edit
that module from including 'module' to 'moduleVERSION' have we made a
usable package?

For collectd, I'd imagine that if you have both 4 and 5, you have
servers for both 4 and 5 as collectors, and you'd just run your bits
on each.  Having both on one box would enable you to query both
systems, but what is the incentive to try and maintain this use case
for the packagers?

Since I started writing this there has been another thread about
bringing Puppet current.  And well...

Here are two options as I see it (not including continuing on in this
inconsistent manner)

- New EPEL package requirement... package name _must_ contain version
number based on upstream's abi/api compatability policy.

Okay.. move past the initial 'bleh' reaction and think about it.

Then.. take the recommendation one of my co-workers provided:

- A new EPEL repository path.  EPEL-rolling (or current or whatever).
You can enable this repository if you want to stay with current
packages.

And if you have stuph you don't want rolling forward you still have
several choices:

1: Manage your own local repo collection
2: Set excludes on those packages
3: Just leave the rolling repo disabled except for when you need to do
an update.

I've a few other thoughts on this but don't want to over load this
already full post.

-greg