On 15 August 2012 15:31, BJ Dierkes <de...@bjdierkes.com> wrote: > On Wednesday, August 15, 2012 at 4:22 PM, Stephen John Smoogen wrote: >> On 15 August 2012 15:13, BJ Dierkes <de...@bjdierkes.com >> (mailto:de...@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
