Bundle a newer version of a python library for a point release?

[Kevin Fenzi]

On Fri, 20 Aug 2010 10:58:24 -0700
Jesse Keating <jkeating at j2solutions.net> wrote:

> Here is the situation.  In EPEL6 we'd like to ship Trac 0.12.  This is
> the latest upstream release and since upstream tends to do db format
> changes between releases we'd like to start with the newest one and
> run with it.
> 
> However trac 0.12 requires python-genshi 0.6, and RHEL6(.0) will ship
> with python-genshi-0.5.x.  I've put in an RFE to get that updated in
> RHEL6.1.  There is good chance, but not a guarantee that this will
> happen.
> 
> One way out of this situation I see is to (temporarily?) bundle
> python-genshi 0.6 with the Trac package, solely for the use of the
> Trac package.  It'd require that Trac maintainers become bugzilla
> watchers (somehow...) of python-genshi so that we can see any bugs or
> updates and make sure they get applied if necessary.

I think bundling is a bad idea. 

> I really don't want to ship trac 0.11 with EPEL6.  It won't likely
> have a super long life upstream which would put us in a bad situation
> of having to support it ourselves and try to roll security fixes for
> it ourselves (which was !fun on older EPEL branches for older Trac).
> The only other option I see here is to withold Trac from EPEL6 until
> (maybe?) RHEL6.1 which also doesn't seem like a fun option.
> 
> Looking for other ideas, or thoughts on the above.  Thanks!

Submit a 'python-genshi-06' package and have track 0.12 use that
instead of the base python-genshi?  You would need to of course make
sure they could parallel install. 

kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20100820/503c29ed/attachment.sig>