* 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.
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!