Request to allow an incompatible upgrade
 

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




_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Request to allow an incompatible upgrade
 

On 15 August 2012 15:31, BJ Dierkes <derks@bjdierkes.com> wrote:
> 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

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

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

If it is a hack in EPEL, how can we do this better?

> References:
>
> [2] http://iuscommunity.org
>
> ---
> derks
>
>
>
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list



--
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Request to allow an incompatible upgrade
 

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
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list