So we have centosplus and extras which are the repos with "access denied" for packages inclusion. Dag's rpmforge which is so huge with a lot of dependencies not suitable for "testing/bleeding edge/alternative" packages. So what's the suitable repo? That's why people are going to run own repos.... :o( I do it myself.
We even have centos.karan.org, with all the packages for 5 in... "testing", since 2007. Oh boy.
Too many repos, working or not, with packages frozen in testing or not, and this is exactly why I needed my tiny repo to partially "fix" the RPMforge<->EPEL breakage with regards to the exact RF packages I am interested in, and also to add packages that couldn't go into EPEL (like a newer GIMP that would not require any other library update), etc.
So no, I don't have a problem with Dag, as someone suggested. I only find partially-broken repos "not Zen" (bad karma, if you wish), and it's even worse when their SRPMs can't build.
But I *do* have a problem with RPM Fusion and Karanbir's repo, because they keep packages in "testing" even if nothing happens (they could stay there until 2014, right?).
RPMRepo is the best proof that collaboration is close to impossible.
And ElRepo is the best proof that other small repos could arise, and they have a reason to exist.
But all this is on the "expenses" (not pecuniary, but *nervous*) of the end user, who will get confused and who might also experience system breakage. (No, priorities don't fix everything that easily.)
Cheers, R-C
__________________________________________________________________ The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
On Tue, 30 Jun 2009, Radu-Cristian FOTESCU wrote:
But I *do* have a problem with RPM Fusion and Karanbir's repo, because they keep packages in "testing" even if nothing happens (they could stay there until 2014, right?).
oh _+please+_ troll elsewhere .. no-one forces you to use any third party repository, and you are late to the game.
http://www.owlriver.com/projects/packaging/ has not been materially updated for over five years, because there is no longer any material purpose to it.
EPEL decided [was arm-wrestled to submission by @redhat's ;) ] to continue down the 'there can be only one' path Warren announced long ago in 'fedora.us'. I disagree. We are both right, and I address the matter by not using third party binary archives and building all the time https://www.redhat.com/archives/epel-devel-list/2007-May/msg00156.html
Red Hat as a commercial entity has much to lose from a lawsuit alleging contributory infringement (patented codec's, etc); Red Hat owns Fedora, and Red Hat owns EPEL. End of story as they have a duty to to be risk adverse to their shareholders
'amicable 'federation' is about all that one can achieve' Not the end of the world -- not hard -- and I publish the fruit I grow.
-- Russ herrold
On 06/30/2009 03:46 PM, Radu-Cristian FOTESCU wrote:
We even have centos.karan.org, with all the packages for 5 in... "testing", since 2007. Oh boy.
yes, perhaps the english language is alien to you - the word 'testing' means something, there is a reason why those packages are there in 'testing' - people who dont know what they are doing are recommended to NOT use them.
- KB
Radu-Cristian FOTESCU wrote:
RPMRepo is the best proof that collaboration is close to impossible.
Collaboration isn't exactly the point - in fact the differences are a good thing. There are legitimate reasons (besides the obvious differences of opinions) for incompatibly different versions of things to exist and to be wanted on different machines. The problem is not so much that these differences exist, but that the potential users (A) don't have a good way to know what the differences are and why they might want one version over another, and (B) the distro tools are not good at all at maintaining updates from a bunch of different repositories.
And ElRepo is the best proof that other small repos could arise, and they have a reason to exist.
But all this is on the "expenses" (not pecuniary, but *nervous*) of the end user, who will get confused and who might also experience system breakage. (No, priorities don't fix everything that easily.)
Exactly - but it's not the repo's fault that your system is easily broken. It is that the system was designed to only give you one choice and can't even track where a package came from to get updates only from the same place. But it was unrealistic to ever believe that one choice would be enough, particularly when the base repository has policies that dictate what can be there.
can dag & karanbir sort of sum up this thread as to how list members can work together on improving all the additional non-redhat-originated packages from rpmforge,etc.
As for radu-cristian, relax bro. As for others (myself included), lets all chill out. this thread should not
evolve into personal attacks. venting happens once awhile. so lets all work together to keep making centos a good cholce for users.
----- Original Message ----
From: Les Mikesell lesmikesell@gmail.com To: CentOS mailing list centos@centos.org Sent: Wednesday, July 1, 2009 8:42:02 AM Subject: Re: [CentOS] Dag's comment at linuxtag
Radu-Cristian FOTESCU wrote:
RPMRepo is the best proof that collaboration is close to impossible.
Collaboration isn't exactly the point - in fact the differences are a good thing. There are legitimate reasons (besides the obvious differences of opinions) for incompatibly different versions of things to exist and to be wanted on different machines. The problem is not so much that these differences
exist, but that the potential users (A) don't have a good way to know what the differences are and why they might want one version over another, and (B) the distro tools are not good at all at maintaining updates from a bunch of different repositories.
And ElRepo is the best proof that other small repos could arise, and they have a reason to exist.
But all this is on the "expenses" (not pecuniary, but *nervous*) of the end user, who will get confused and who might also experience system breakage. (No, priorities don't fix everything that easily.)