[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: rpmforge and {enterprise, } Extras (Was Re: Initial Proposal for doing Enterprise Extras=

Talk of an RPMForge / Extras work-together-for-the-common-goal makes me happy. Some of the .spec's in Extras today found root in the rpmforge tree's and the guys there - dag, dries, thias etc have done a fair bit of work over the years, throwing community behind the same goal would be nice way to carry on these efforts.

I have some understanding about rpmforge and am in regular contact with the people behind it, and will try to answer these questions as best as I can. [1]

Thorsten Leemhuis wrote:
Well, after my first more diplomatic shot I'm willing to touch more
dangerous grounds now.

There are afaics (and *please* correct me if I'm wrong) some more big

- rpmforge wants to (or does already?) build for distributions like Suse
or SLES (someone indicated that to me in private on IRC some weeks ago)

I am not sure what the intended significance of this point is ? Does FExtras not want their spec's used elsewhere ? hey, why only SuSe, I'd love to see even MDK etc using the same spec - we only gain from a broader testing/ user base.

but apart from that, afaik, rpmforge isnt building/ hosting any non Fedora/Redhat/Aurora builds.

There were two more in the past, I don't know if they are still valid:

- rpmforge now and then replaced packages from the the distributions is
was build for (RHEL, Fedora Core and Extras, which i consider as a
integrated part for Fedora Core, but that's just my view);

I too, have some issues on this front - I dont think we should be replacing pkgs from [base], specially not on a supported platform like EL. However, once a distro is in Maint mode, should this then be allowed ? Also, for still supported distros : could such packages be split into a seperate repo ( CentOSPlus sorts ? ) and then let users make the decision ?

- rpmforge builds new packages often for several distributions including
those that are in "Maintenance state" (FC3, FC4 currently); Fedora
Extras is more conservative here

True, but this policy at Extras will need to change quite dramatically if and when Enterprise Extras comes into play, remember - 7 years from now, EL4 will still be a supported platform...

The current move to build for centos, EL etc means that this
fundemental difference should disappear. Of course, rpmforge provides
many useful packages which couldn't move into FE/EE - it wasn't my
intention to suggest a merger.

Well, why not? Merge the stuff into Extras that can be there; merge the
other stuff with livna and atrpms and everybody is happy because "repo
wars" would be mostly history then.

+1 for that, why even have a livna/atrpms/rpmforge building for the same stuff. Setup a shared svn, and let the builders do their thing. If there is potential for this, I am happy to be the one to co-ordinate with people. ( even if that includes screaming/ yelling / name calling etc - I've developed a rather hard skin over the last few years )

Yeah, but what can Fedora Extras offer them?

I think we all need to take a user specific view on some of these things. I know that FE can offer rpmforge a lot, and similarly rpmforge can offer stuff back.

thl, going back to your statement - perhaps we should not consider this as FE/RPMForge at all - but FE/other-repo's-that-build-with-the-same-target. Atleast on a longer term position.

And there are also different goals
in FE and rpmforge that will make a merge even more complicated -- I
 > It would be helpful if dag and dries could share their view on this idea

I dont speak for RPMForge, but perhaps we could start with a set of pkgs where the goal isnt divergent. And there isnt any Licensing issue...

- KB

[1] I had already been doing some work on getting the repo's at centos.karan.org ( FE rebuilds for CentOS ) and the El4/EL5 branch of RPMForge to merge, and then get the CentOS community to get involved in expanding the project there.

Karanbir Singh : http://www.karan.org/ : 2522219 icq

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]