On Mon, Jun 2, 2008 at 3:16 PM, Stephen John Smoogen <[EMAIL PROTECTED]> wrote: > On Mon, Jun 2, 2008 at 12:27 PM, Michael A. Peters <[EMAIL PROTECTED]> wrote: >> Bill Nottingham wrote: >>> >>> Stephen John Smoogen ([EMAIL PROTECTED]) said: >>>> >>>> I don't think we have one. We have dealt with the older policy where >>>> things conflicted with 5.1 but not 5.0. >>>> >>>> What exactly are the packages having problems? >>> >>> gtkhtml3 was rebased in 5.2, changing ABI. We can ship (in EPEL) >>> a gtkhtml38 package, but it will conflict at the file level with >>> gtkhtml3 from 5.1 and earlier. >>> >>> Bill >> >> I suppose there was a very good reason for the base change, but I thought >> things like this are one of the issues using RHEL was suppose to avoid. >> > > The problem is that there are 2 customer demands that RH is trying to meet: > 1) Newer software for the desktop so that OpenOffice/FireFox are able > to use newer tools > 2) Older software for the desktop so that OpenOffice/Firefox stick to > the same data forever. > > The way RH 'solves' this is by having minor branches.. so people who > want to avoid the problem can stick with the 5.1.x tree. This is where > EPEL, CentOS, SciLin, DAG etc. are going to run into problems. To meet > a majority of customers we need to have several trees that we compile > and test from. > > 4.5.x? > 4.6.x > 4.7.x > 5.1.x > 5.2.x > 5.3.x Sanity's mom called, she said he was missing.
Wow. That's painful on so many levels. Why not just create a separate Desktop vs Server platform and be done? Keep ABI in some tree but not the next but maybe this one, but when I upgrade some apps like it and some don't. You've successfully confused even the longest of RHEL users. If they want modern Firefox/OOo, use Fedora. Isn't that the point? I need ABIs that don't break when I type yum update. That's the bottom line for an enterprise. stahnma > ..... > > And that's a lot of RPMs/bandwidth after a while. If we just move the > branch to 5.2 then 'customers' who are sticking to 5.1.x are going to > be dead in the water with EPEL. If we branch we are going to need to > come up with appropriate repo-tags to separate branches for people. > > > -- > Stephen J Smoogen. -- BSD/GNU/Linux > How far that little candle throws his beams! So shines a good deed > in a naughty world. = Shakespeare. "The Merchant of Venice" > > _______________________________________________ > epel-devel-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/epel-devel-list > _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
