Odiecolon repo for EL5

Radu-Cristian FOTESCU beranger5ca at yahoo.ca
Mon Jun 29 17:49:57 UTC 2009

> * packages that are excluded from EPEL for legal reasons.
> RPM Fusion can hold them however and is meant to be 
> compatible with EPEL.

If RPM Fusion is supposed to be "a better RPMforge", then
I beg to opine that it fails.

I would never use a repo which has 99% of the packages
in folders labeled "testing". 

It's like using EPEL-testing, which I am not using. But
with RPM Fusion, you *have to* use the "testing" section!

Plus, it doesn't really match RPMforge's multimedia offerings
(e.g. MPlayer *and* VLC).

Moreover, knowing that RPM Fusion took years to come alive,
even for Fedora, this doesn't make me trust it. It still has
to prove it's as accountable for as EPEL. (Or maybe I'm 

To put it one more time: as long as the ~126 RPMforge packages 
won't be *all* in the "release" place instead of "testing",
I won't even be considering that repo!

> I suggest that you work with EPEL on packages that are
> cleanly in the first category initially. 

Where would GIMP 2.3.15 fit into the picture? (Just an example.)

> The benefit is shared infrastructure (koji, bodhi et all)
> that brings the packages you are interested in to more
> architectures and a community for reviewing packages

Indeed, these are undeniable advantages. 

> Sounds reasonable?

The concepts, yes. 
But do *I* sound reasonable? (Most often... not quite so.)

Oh, and how about ElRepo? Shouldn't they be integrating with EPEL too?
Except maybe for NTFS, I don't see legal reasons for why not.

Don't shoot the confused piano man.

Looking for the perfect gift? Give the gift of Flickr! 


More information about the epel-devel-list mailing list