'policy' for multiple versions of same software in EPEL

[Toshio Kuratomi]

On Mon, Oct 22, 2012 at 01:41:36PM -0500, Greg Swift wrote:
> On Thu, Oct 18, 2012 at 10:38 AM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> 
> > 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?
> 
Unfortunately, there's not a lot you can do about that (although many
upstreams have worked on this problem off-and-on in various ways and it
might be possible to work out something depending on the language you're
dealing with.  For instance, with python you're able to specify the version
you want in one place in your application and then that's the version that
will be used anywhere the library is imported).

If you replace a library with a new library that is incompatible, then you
inconvenience anyone that is using the library that EPEL shipped with.  If
you don't update then you inconvenience anyone that is using or wants to use
a newer version of the library.

The current policy of EPEL is geared towards people who have deployed based
on what's currently in EPEL rather than those who want to deploy something
new.

As for non-upstream patches... we are against them but not as much as other
things. Non-upstream patches aren't a guideline in the Fedora packaging
guideline, for instance.  Keeping non-upstream patches to a minimum allows
a package maintainer to do more work with their limited time.  But there are
things about packaging that sometimes require patching even if the upstream
won't accept them.  For instance, a patch to run against an older version of
a language even though the upstream doesn't care about that version anymore.
Figuring out how to utilize a different version of a library is just a short
step away from that.

> 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.
> 
Yep.  Debian (which releases on a timeframe that's more like RHEL than
Fedora) applies something like this to their C libraries.

> 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.
> 
I think a lot of people like this but no one is prepared to become the guy
who's responsible for maintaining it.  A new repository has both setup costs
and long term maintainance costs.  You can take a look at past list
discussions for some ideas of those costs and then see if you can come up
with a plan for how to meet the manpower requirements to make this work.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20121022/85669b8b/attachment.sig>