'policy' for multiple versions of same software in EPEL

[Kevin Fenzi]

On Fri, 12 Oct 2012 22:35:03 -0500
Greg Swift <gregswift at gmail.com> wrote:
> 
> I'm all for that.  Technically its one of the benefits of them being
> different package namespaces that conflict, you won't get a change you
> don't force with intent :)

Right. It would be something end users would have to specifically do... 

'yum remove foo' 
'yum install foo2' 

...snip...

> > Right. I think this may be something we want to ask the Fedora
> > Packaging folks (who live on the packaging list) about.
> 
> good plan

Can you post over there about this and look for feedback?

> > The main problem with conflicts is that it's something that is
> > detected by yum at the 'test' stage. It means you have chosen,
> > downloaded a bunch of stuff and then yum tells you, "WOAH, these
> > confict, fix it and try again". This is not very friendly. If you
> > do this in the installer it's even worse.
> 
> that is unfortunate

yes, it sure is. ;( 

> hmm... still tough to justify running simultaneous on the same server.
>  Maybe I've just always had machines available (both virtual and
> physical) .  That being said, i wonder if we make the packages support
> --prefix if the customer can override and make it work?
> 
> I just don't think we should spend a lot of time and resources trying
> to make something work for the sub1% that are doing something uncommon
> and special in the first place.

True. I do see your point... 

> However, If one of the people that wants that wants to chip in and
> provide use case, testing, and preferably patches that would be
> awesome.

yeah. 

...snip...

> They are decidedly incompatible versions, but definitely the same
> stack and namespace.  since they run on the same version of ruby, its
> not like we get a separation that way.
> 
> For any EPEL users that use rubygem-rspec (which has nothing built
> against it.. see footnote in previous message), the rubygem-rspec2
> would be a conflict and non-obsolete so they could keep on keeping on,
> even update if there was one (which I don't believe there is or ever
> will be based on rspec state).
> 
> With this example, i don't see why you'd want both versions.  However,
> I know that is not always going to hold true.
> 
> I guess maybe a series of scenarios being documented with suggestions
> on handling would be best?

yeah. That would at least help us see what all the combos do/are. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20121017/1222dd06/attachment.sig>