[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: 5.1 -> 5.2 move

On Mon, Jun 2, 2008 at 3:16 PM, Stephen John Smoogen <smooge gmail com> wrote:
> On Mon, Jun 2, 2008 at 12:27 PM, Michael A. Peters <mpeters mac com> wrote:
>> Bill Nottingham wrote:
>>> Stephen John Smoogen (smooge gmail com) 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.


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

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.


> .....
> 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
> epel-devel-list redhat com
> https://www.redhat.com/mailman/listinfo/epel-devel-list

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]