[CentOS] Re: mplayer repository for CentOS

[Bryan J. Smith]

On Sat, 2005-05-21 at 07:58 +0200, Dag Wieers wrote:
> What is your plan when Fedora Extras is doing Fedora Core 5 and Fedora 
> Core 6 only and you'r stuck with RHEL4 systems ? If you can rely on Fedora 
> Extras now it's because you don't have RHEL2 or RHEL3 machines I guess.

I'm still using FE/Lorg for RHEL3.  But we are also moving our RHEL3
systems to RHEL4 too.  Also remember I maintain my own, internal
repositories, so rebuilding from SRPM does not bother me at all.

What I think you're getting into is more than technical, but it's
support and philosophical.  In reality, I try to _avoid_ anything that
Red Hat does not ship, because it is not supported.  My whole reason for
running RHEL is the SLA.

When I don't need the SLA, I'm staying with Fedora Core.  I'm rotating
systems every 12 months in that role, so there that is not an issue.  I
am basically the guy writing the Linux standards manual against existing
UNIX standards manuals, and having to document variations to it anyway.

So adding in a few packages is not much of a load at all.  Because
unless Red Hat itself ships it, it's my butt on-the-line.  So I don't
trust you anymore than FE, Lorg, etc...  ;->

If the CentOS project continues its fine job of not only rebuilding
SRPMS, but offering extra repositories supported for a period of time, I
think Red Hat will have to take notice that it's not doing a good job as
curator of the greater Fedora Project.  Of course, being a staunch
independent is not the best course of action -- and I can appreciate
many members of both Red Hat and the Fedora team (Seth, many of the RHEL
developers, etc...).

I the more Red Hat fails to address the FC-RHEL revisioning/depencency,
I think the more people like myself -- system integrators and
maintainers -- will look at SL/NL instead.  And that's really going to
be the "wake up call."  Especially if Novell makes good on its public
comments that it is looking to "Fedorize" SuSE Linux.

> The inconsistency is (partly) the result of not caring about backward 
> compatibility in SPEC files (but also userland utilities and RPM itself).
> Whatever they improve now in RPM, we will have to live with RPM from 
> RHEL2, RHEL3 and RHEL4 for a long time. So whatever new features are being 
> used in SPEC files, if Fedora Extras adopt those, you lost support for 
> rebuilding Fedora Extras stuff. Things like that already happened, try 
> compiling Fedora perl packages on RHEL3 and you'll see what I mean.

But I've seen the same in the Debian world too.

If you're saying that Red Hat needs to take notice that they need to be
wary of the damage that is caused by not considering older versions when
designing SPEC files, I agree.

But I'm also sure much of this has to do with the fact that Red Hat no
longer bothers to regression test their packages on older versions.  So
they probably consider the effort on the SPEC file to be only "half-way"
and not worth the effort, and I also have to agree.

I can see the argument both ways.  I can understand your reasons.  But I
can also understand the Fedora Project's.  And even knowing the Debian
Project's, there's still no simple 'requirement' to follow.

> Fedora == Development, at a fast pace, not looking back, it contradicts 
> with the reasons you go with RHEL.

If this is indeed the case, then RHEL is doomed.
And Red Hat will wake up too late.

So far, based on Fedora Core 1 and Fedora Core 3, Red Hat seems to be
maintaining much of the Red Hat Linux revisioning, even if it is hidden.
But if they continue to allow "from the hip" changes like GCC 4.0 and
other things -- without a consistent 0-1-2 or at least a 0-1 release
model, then I think RHEL is doomed.

> Bryan, that's more a apt/yum issue than it is a repository issue. If you 
> think repository maintainers should divide their repository in all 
> possible permutations of what people might want (and what 
> cross-requirements exist between these repositories), you have not 
> maintained a big repository. Believe me, this functionality should go into 
> Yum (apt has hte functionality, but apt is dead anyway).

Have you talked to Seth about this?  I know he is always looking for
input/help in many YUM developments, at least based on his posts/blog.

> Smart can do it and if you're a RHEL4 user, I would recommend Smart as it
> allows you to specify what you want and don't want from whatever
> repository you add.

I'll look into Smart.  I am totally ignorant of what it is.

> It should go into Yum, because only the user knows what policies it 
> requires for their business and it gives much more flexibility.

That's an interesting viewpoint.  You obviously have more experience in
maintaining revisions on many packages more longer-term than I.  So I
have to concede this.

My support has either been of fewer packages over a long-time for RHEL
(and, more limitedly, CentOS), or just "keeping current" over a year of
RHL and, now, FC.


-- 
Bryan J. Smith                                     b.j.smith at ieee.org 
--------------------------------------------------------------------- 
It is mathematically impossible for someone who makes more than you
to be anything but richer than you.  Any tax rate that penalizes them
will also penalize you similarly (to those below you, and then below
them).  Linear algebra, let alone differential calculus or even ele-
mentary concepts of limits, is mutually exclusive with US journalism.
So forget even attempting to explain how tax cuts work.  ;->