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 ..... 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
