From: William Warren hescominsoon@emmanuelcomputerconsulting.com
considering the FUD fedora talks about mixing repositories.
It's not FUD, it's an issue with Debian as well.
From what I've seen, for the most part, as long as you pick one or the
other repository, you're okay. E.g., either DAG or FE+Lorg.
One of the reasons for the greater Fedora Project (outside of the Fedora Core name change and trademark issues) was the continued sprawling of repositories. Fedora Extras was supposed to address this, but even I'll admit that it seemed a little too much "you're on your own" in the first 18 months of its existance. I.e., the former U of Hawaii Fedora Project didn't do much to help anyone but their own, existing project set, and the new Livna.ORG repository fork (for legal reasons).
But as of this year, there is now a formal submittal process. And being a software engineer myself with a lot of experience in formal lifecycle and testing, I kinda prefer the quality I see out of Red Hat's regression and other testing. Maybe it's because I had horrors with FreshRPMS before I switched to Fedora.US (before Red Hat's involvement), and instantly saw many issues go away.
But FE/Lorg seems to have everything I want. Only a couple times have I tapped DAG, and then I only did it temporarily in my APT/YUM files to avoid "repository mixing" issues anytime I did an upgrade later.
BTW, just so everyone know, this e-mail was _not_ to argue the merits of "which repository is better / sucks." I was just interested in finding out if anyone is like me, tapping FE/Lorg, or if most everyone is just using DAG. That's all. I might try a few systems under test and see how it all goes.
-- Bryan J. Smith mailto:b.j.smith@ieee.org
On 5/20/05 9:37 AM, Bryan J. Smith b.j.smith@ieee.org wrote:
BTW, just so everyone know, this e-mail was _not_ to argue the merits of "which repository is better / sucks." I was just interested in finding out if anyone is like me, tapping FE/Lorg, or if most everyone is just using DAG. That's all. I might try a few systems under test and see how it all goes.
FWIW, under RH/FC I typically used Fedora Extras and Livna, grabbing DAG packages only when I was in a real hurry. I haven't yet tried to integrate either repo into CentOS 4.
On Fri, May 20, 2005 11:37 am, Bryan J. Smith b.j.smith@ieee.org said:
From: William Warren hescominsoon@emmanuelcomputerconsulting.com
considering the FUD fedora talks about mixing repositories.
It's not FUD, it's an issue with Debian as well.
I don't know if I would call it FUD ... BUT, if repos are going to work together, they have to use consistent names for packages, so that versioning will work properly.
From what I've seen, for the most part, as long as you pick one or the
other repository, you're okay. E.g., either DAG or FE+Lorg.
Since they don't do what I said (work togther to maintain naming for versioning), then picking one or the other is the safest thing to do.
Just for the record, using the Fedora Core library on CentOS-4 can be problematic (and even DAGs repo, for that matter) ... in that both can overwrite base CentOS libraries. I would highly recommend that you use a includepkg= in your yum configuration for any external repo (even things like centosplus).
Karanbir Singh is working on a rebuild of FC Extras that uses functionality already in CentOS-4 and doesn't upgrade any packages (unless required) that are part of the base centos. Since FC is not CentOS, and there are differences in some libraries, I would recommend Karanbir's repo over FC Extras (for CentOS-4). I don't have the address of this site handy right now...I'm sure someone does.
I use Dag for stuff all the time by enabling it when I need it, and being careful what I let it install ... it is a great resource. Dries is good as well.
Just be careful when using any external repo, as it can replace things you don't want.
On Fri, 2005-05-20 at 12:39 -0500, Johnny Hughes wrote:
<snip>
Karanbir Singh is working on a rebuild of FC Extras that uses functionality already in CentOS-4 and doesn't upgrade any packages (unless required) that are part of the base centos. Since FC is not CentOS, and there are differences in some libraries, I would recommend Karanbir's repo over FC Extras (for CentOS-4). I don't have the address of this site handy right now...I'm sure someone does.
Here is the repo that Karanbir has done (Fedora Core Extras for CentOS-4):
On Fri, 20 May 2005, Bryan J. Smith b.j.smith@ieee.org wrote:
From: William Warren hescominsoon@emmanuelcomputerconsulting.com
considering the FUD fedora talks about mixing repositories.
It's not FUD, it's an issue with Debian as well.
The FUD is related to the fact that fedora.us was never interested in working with existing repositories. With Fedora Extras it didn't much improve in the sense that the only way they listen is if you're part of the team and the only way to be part of the team is to sign legal papers.
So they introduced (and are introducing) stuff that breaks my stuff and they don't care.
And it wouldn't even help as they're not doing RHEL packages and fork for different distributions. They actually only support the latest Fedora release and the previous Fedora release. So tough luck if you want RHEL2, RHEL3 (and when Fedora 5 is released RHEL4 packages from Fedora Extras probably don't build because of changes).
So you're basicly mixing a philosophy (Fedora Core development, not looking back) and the philosophy that says, keep compatibility with older distributions, and only fork when maintaining a single SPEC file is more costly than forking.
It's true that RPMforge does not offer any more than the packages and the ability to help out by reporting problems. So if you have problems with any of the packages, report it, otherwise we can't help.
BTW Much of the rest of your email was pretty incorrect about the history of Fedora and existing repositories. But I guess you weren't around back then :)
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Sat, 2005-05-21 at 07:46 +0200, Dag Wieers wrote:
The FUD is related to the fact that fedora.us was never interested in working with existing repositories.
I was wondering when you'd join the conversation. ;-> First off, I never said they did.
With Fedora Extras it didn't much improve in the sense that the only way they listen is if you're part of the team and the only way to be part of the team is to sign legal papers.
From my understanding, as of January, they have a formal package
submission processor whereby you do not. I've been talking to a few people about adding my own.
Unless, of course, you want to have your own, "independent" repository, and use the formal name. Yes, that's a legal thing then, and unavoidable.
So they introduced (and are introducing) stuff that breaks my stuff and they don't care.
Someone "has to be the master." It's just reality. It is the same deal in the Debian world.
And it wouldn't even help as they're not doing RHEL packages and fork for different distributions. They actually only support the latest Fedora release and the previous Fedora release. So tough luck if you want RHEL2, RHEL3
I think that is now changing that it is now more formalized. Prior to January, it was largely just the former U of Hawaii. But now I'm seeing FE and, even more so, Lorg supporting all the way back to at least FC1. That means I'm good for RHEL3 so far -- although I admit no one can predict the future.
Not to step on your continued good will and endeavors, but how much regression testing do you do of your packages before you put them out? If it compiles, great, if it builds, ship it? That's what I assume it is?
(and when Fedora 5 is released RHEL4 packages from Fedora Extras probably don't build because of changes).
Possibly. I've been very, very critical of Red Hat's current "revisioning strategy" (or lackthereof) with Fedora Core and I believe it's ultimately going to affect their RHEL release quality. There's absolutely no reason for this, but I think some people have forgotten the stilts that RHEL is built on -- just like RHL before it.
Which is why I'm seriously considering moving to SuSE Linux, because Novell seems to have a formal Novell-SuSE strategy that ties well together. We'll see as of NL10, SL10.x, but I'm hopeful.
So you're basicly mixing a philosophy (Fedora Core development, not looking back) and the philosophy that says, keep compatibility with older distributions, and only fork when maintaining a single SPEC file is more costly than forking.
Make no mistake, I'm _no_fan_ of Red Hat's "undeclared" strategy on Fedora Core, and the greater Fedora Project in general. They are starting to take more of a "pro-active" interest in the greater Fedora Project as of January, and that's good.
It's true that RPMforge does not offer any more than the packages and the ability to help out by reporting problems. So if you have problems with any of the packages, report it, otherwise we can't help.
BTW Much of the rest of your email was pretty incorrect about the history of Fedora and existing repositories.
Can you be specific? Please correct my misinformation then, for all our benefit (including my own). A lot of my information comes from being on the Red Hat lists, talking to Red Hat employees as well as the Red Hat marketing to try to repair a lot of the damage that eWeek's mis-quotes of Michael Tiemann did back in 2003.
I started using the U of Hawaii Fedora Project as of early 2003. Before that I used FreshRPMS.NET since mid-2001. I have been using your repository on and off since late 2003 as well.
I took an interest in Connectiva's port of APT to RPM early on, and even started using it as a means of configuration management internally. When the independent repositories started springing up, that was just a bonus.
But I quickly found the U of Hawaii's APT-RPM to be the best -- at least compared to FreshRPMS.NET. The first major difference I noticed was how it handled kernel upgrades. Again, I admit I had not looked at your repository at that time, and I full claimed ignorance in an earlier post.
But I guess you weren't around back then :)
No, I wasn't actively involved with Red Hat Linux development, just on the Red Hat and other lists as a lurker. I have contributed bug fixes and package changes here and there, but nothing major. Most of it has largely been kernel-related (since 1994) but, again, nothing really notable at all.
I've been integrating Red Hat Linux into corporate networks for more than just web services (e.g., file servers, engineering build systems, etc...) since Red Hat Linux 4.2 (and various distros for various web duties before even Apache was formalized). Again, once APT came over to RPM thanx to Connectiva, it was the needed tool to help out with distributed configuration management of a Linux network.
Unlike many people in the '90s, I wasn't just using Linux as a rogue Samba or Apache server. I had distributed engineering workstations and computational networks -- so I was maintaining dozens of systems on an network, and not just one or two I could patch manually.
On Sat, 21 May 2005, Bryan J. Smith wrote:
On Sat, 2005-05-21 at 07:46 +0200, Dag Wieers wrote:
With Fedora Extras it didn't much improve in the sense that the only way they listen is if you're part of the team and the only way to be part of the team is to sign legal papers.
From my understanding, as of January, they have a formal package submission processor whereby you do not. I've been talking to a few people about adding my own.
How's that going to work ? If a package has no maintainer, it is orphaned. You need to sign the legal papers to be able to maintain a package (ie. get CVS access). Anyway, that wouldn't be a solution as they don't care about RHEL, so you'll have to fork anyway and manage the forks.
Unless, of course, you want to have your own, "independent" repository, and use the formal name. Yes, that's a legal thing then, and unavoidable.
Why would someone want to do that ? What are you implying ?
So they introduced (and are introducing) stuff that breaks my stuff and they don't care.
Someone "has to be the master." It's just reality. It is the same deal in the Debian world.
Well, if we have to have a master, then give me a kind one :-)
And it wouldn't even help as they're not doing RHEL packages and fork for different distributions. They actually only support the latest Fedora release and the previous Fedora release. So tough luck if you want RHEL2, RHEL3
I think that is now changing that it is now more formalized. Prior to January, it was largely just the former U of Hawaii. But now I'm seeing FE and, even more so, Lorg supporting all the way back to at least FC1. That means I'm good for RHEL3 so far -- although I admit no one can predict the future.
Livna.org is working differently and better to that respect.
Not to step on your continued good will and endeavors, but how much regression testing do you do of your packages before you put them out? If it compiles, great, if it builds, ship it? That's what I assume it is?
Correct, test it yourself is what you have to do now. Want to help out and start doing regression tests ? It's the same for Fedora Extras on RHEL by the way. Tough luck running Fedora binaries on RHEL.
RPMforge is only with 4 (+ all the people that give feedback), we invite people to help us out. If you think something is important enough, don't waste your time, do something about it :)
BTW the testing that I've seen with FE is often also not more than QA of the SPEC file (most of our stuff is much more consistent in that area). Of course there is a big difference between the important packages and the seldomly used ones.
(and when Fedora 5 is released RHEL4 packages from Fedora Extras probably don't build because of changes).
Possibly. I've been very, very critical of Red Hat's current "revisioning strategy" (or lackthereof) with Fedora Core and I believe it's ultimately going to affect their RHEL release quality. There's absolutely no reason for this, but I think some people have forgotten the stilts that RHEL is built on -- just like RHL before it.
Which is why I'm seriously considering moving to SuSE Linux, because Novell seems to have a formal Novell-SuSE strategy that ties well together. We'll see as of NL10, SL10.x, but I'm hopeful.
And you can^Whave to use Yast ! :)
So you're basicly mixing a philosophy (Fedora Core development, not looking back) and the philosophy that says, keep compatibility with older distributions, and only fork when maintaining a single SPEC file is more costly than forking.
Make no mistake, I'm _no_fan_ of Red Hat's "undeclared" strategy on Fedora Core, and the greater Fedora Project in general. They are starting to take more of a "pro-active" interest in the greater Fedora Project as of January, and that's good.
Still they don't have to care about stuff older than 1 year, and that has an affect on newer RHEL releases too, regarding compatibility.
BTW Much of the rest of your email was pretty incorrect about the history of Fedora and existing repositories.
Can you be specific? Please correct my misinformation then, for all our benefit (including my own). A lot of my information comes from being on the Red Hat lists, talking to Red Hat employees as well as the Red Hat marketing to try to repair a lot of the damage that eWeek's mis-quotes of Michael Tiemann did back in 2003.
Look at the mails from 2002 and 2003 on the fedora.us mailinglist, read about the epoch zero and other such decisions and ask yourself why fedora.us failed to attract the existing packagers.
With the backing of Red Hat of course things changed dramatically. Anyway, I do not have the time to reiterate these things, not as much time as you seem to have.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On 5/21/05, Bryan J. Smith b.j.smith@ieee.org wrote:
[ snips ]
...Red Hat marketing to try to repair a lot of the damage that eWeek's mis-quotes of Michael Tiemann did back in 2003.
An what might these misquotes and this damage be? I've done a little googling with those keywords and found nothing of interest. I haven't a clue what you're talking about.
-
Bryan J. Smith -
Bryan J. Smith <b.j.smith＠ieee.org> -
Collins Richey -
Dag Wieers -
Johnny Hughes -
Paul Heinlein