On Wednesday, August 15, 2012 at 4:22 PM, Stephen John Smoogen wrote:

On 15 August 2012 15:13, BJ Dierkes <derks@bjdierkes.com (mailto:derks@bjdierkes.com)> wrote:

...

I am the maintainer, as well as the upstream developer of 'python-cement', a CLI Application Framework for Python [1]. Current version of python-cement in EPEL 5/6 is 0.8.18, however I recently released version 2.0.0 upstream which is the next/current stable version. The 0.8.x/1.0.x branch is dead upstream and no longer maintained, and for that reason I would like to request the ability to break compatibility and upgrade EPEL to the latest stable and supported version of Cement.

This is a completely incompatible upgrade. Applications written on top of Cement 0.8.x would need significant changes (or a full rewrite of all the CLI pieces) to work with Cement 2.0.x. That said, there are no packages in EPEL that Requires: python-cement. Presumably there are users that are using python-cement for non-EPEL software however that is obviously not possible to know whether it is a significant number or not. Based on feedback, I don't think many people are using Cement 0.8.x but I really couldn't say officially.

Currently there are no known bugs or security issues with python-cement in EPEL as it stands, therefore it is not eligible for an 'incompatible upgrade'. That said, based on usage and its upstream status… I figured it wouldn't hurt to ask.

1. Would it be possible to make a package called python-cement2 which

would track this chain and then you could dead package the old one if no one wants to maintain that tree?

I could do that, but it would mean one of two things right?

a) python-cement2 Conflicts with python-cement b) python-cement2 patches the source so the module is 'cement2' (no good)

Using the conflicts model, I would probably rather add it to the IUS Community Project [2] which does that explicitly for all packages, and in EPEL its kind of a hack.

References:

[2] http://iuscommunity.org

--- derks

On Wed, Aug 15, 2012 at 03:53:32PM -0600, Stephen John Smoogen wrote:

On 15 August 2012 15:31, BJ Dierkes derks@bjdierkes.com wrote:

...

I could do that, but it would mean one of two things right?

a) python-cement2 Conflicts with python-cement

We usually go for this unless the module can be dual installed.

All python modules can be dual installed. However, it may require changes to other packages to make use of. We utilize setuptools to install the package as a multiple version (setuptools installs it into an alternate path) and then packages that need the non-default version have to add it to their path somehow. There is a setuptools provided way to do that too:

__requires__ = ['cement >= 2.0'] import pkg_resources

http://fedoraproject.org/wiki/Packaging:Python_Eggs#Multiple_Versions

In EPEL we're carrying a few of these packages for web frameworks since the versions that shipped with RHEL are old or different web frameworks require different versions.

Also note -- Conflicts aren't allowed in fedora packages except under some very specific circumsances. I don't think EPEL has a divergence here.

Also note -- personally I wouldn't mind this or several other packages being free to upgrade. But then agian, I'm not personally a consumer of an old version of them :-)

-Toshio