- 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 delusional.)
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. Thanks, R-C
__________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr!
On 06/29/2009 11:19 PM, Radu-Cristian FOTESCU wrote:
- 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.
It doesn't really have any such goals and would still require among other things a release engineer to move it forward. Hopefully it will be in the near future. You are free to continue carrying whatever packages you need in your repo meanwhile. This is why I suggested moving packages in EPEL when there is a clear path to do so leaving the rest as it is, for now.
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.)
Does it conflict with the GIMP package in base EL? The EPEL policy is not include packages that conflict with base EL packages. If it is parallel installable, it might be acceptable.
The concepts, yes. But do *I* sound reasonable? (Most often... not quite so.)
Seems so. The current structure is
EL = Core supported community EPEL = Community supported extra packages RPM Fusion = Packages excluded from EL and EPEL for legal reasons
You are right that EL portion of RPM Fusion is yet to take off well but EPEL has good momentum that you can take advantage of.
Rahul
On 29.06.2009 19:49, Radu-Cristian FOTESCU wrote:
- 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.
That might happen. Especially if to many people start their own repository instead of contributing to RPM Fusion. It all depends on the people that take care of the packages and the repo.
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!
That is because we look for somebody to do be kind of "release engineer". Nobody really stepped up yet and RPM Fusion is thus for now careful to officially announce support for EL & EPEL. But iwth a bit of help it can get runing properly in one or two weeks afaics.
Plus, it doesn't really match RPMforge's multimedia offerings (e.g. MPlayer *and* VLC).
Can be done, just needs somebody to take care of it. The Fedora maintainer of vlc even showed a bit of interest iirc. Ohh, any mplayer is in the testing repos for EL and EPEL.
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 delusional.)
And you expect people to trust your brand new repo more? How many contributors does it have? What will happen if one or two of them (you for example) get married, one or two childs and a new exhausting new job over the next few months that leaves spare time to nearly 0 hours a week?
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!
Then help RPM Fusion instead of competing with RPM Fusion, which just leads to a situation that RPM Fusion solved in the Fedora land (e.g. the competition between frehsrpms and livna)
[...]
CU knurd
epel-devel@lists.fedoraproject.org
-
Radu-Cristian FOTESCU -
Rahul Sundaram -
Thorsten Leemhuis