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.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Dag Wieers wrote: <snipped>

| In the meantime, I'll be having people complaining about the fact the | rsync or lftp is upgraded, and people complaining that RHEL4 does not have | gaim 1.3.0 or something else they require and ship for older | distributions. We can't have it both ways, smart is the solution for this. | | -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- | [all I want is a warm bed and a kind word and unlimited power]

I've built a gaim 1.3.0 rpm. It installed for me on my machine. Would you like this rpm sent to you or is it a non-issue? One must be advised, it's the second rpm I've ever frickin' built and I used your spec file for the previous version of gaim. I just changed a couple of lines to increment the version. It built and seemed as functional as the previous version.

I believe you have a howto or three on your site I may want to go have a gander to see if there's anything special involved in that.

- -- Alex White prata@kuei-jin.org Fingerprint = 58DC 9199 CE73 74E8 B2C1 442E ACF5 92E0 E068 C46C gpg key location: http://www.kuei-jin.org/GPG-KEY-PRATA ~From the withered tree, a flower blooms --Zen Proverb