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.bad...@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
pgpzmrn72u1iO.pgp
Description: PGP signature
_______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
