On Fri, 12 Oct 2012 22:35:03 -0500 Greg Swift <gregsw...@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
signature.asc
Description: PGP signature
_______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
