'policy' for multiple versions of same software in EPEL

Greg Swift gregswift at gmail.com
Tue Oct 23 14:45:21 UTC 2012


On Mon, Oct 22, 2012 at 2:53 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> 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.

Okay... I took its mention in the guidelines as more of a strong
recommendation, especially due to the 'If you think that your package
should be exempt from part of the Guidelines, please bring the issue
to the Fedora Packaging Committee'.  Thanks for explaining that.

https://fedoraproject.org/wiki/Packaging:Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment

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

I can see leaving the number off for the initial version, although in
the long run for EPEL i think it'd be better to just number them all
(ugly, I know... but considering RHEL support has gone from 7 years to
13 years, new packages are just a reality we are going to have to deal
with).

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

Do you have any thread names or search phrases to recommend? I found
several threads back in 2007, which all appear to be early EPEL.
Unfortunately, the audience and use of EPEL was much smaller then.

Its good to see that there was discussion about how to ensure this
happens in the future.  The repository directory structure does look
like it can still handle the additional repository.

The question then becomes how would it fit into the koji/bodhi work
flow.  Is there a good reference for that? I've read the existing
workflow document on Bodhi's wiki. It seems to me that there would
have to be an additional package state, which may not directly plug
into how bodhi currently works.

NEW ---> PENDING --> TESTING --> STABLE --> OBSOLETE
                                            \--UNSTABLE--/------------/

With an UNSTABLE package also being able to push into STABLE if the
STABLE package is no longer considered safe to run (that unsupported,
or no available patch for security issue, or whatever.. would define a
list)

Or the UNSTABLE package would just live in UNSTABLE unless it gets
sent to OBSOLETE.

-greg




More information about the epel-devel-list mailing list