(sorry for the late reply, I was quite busy with other stuff)
Karanbir Singh schrieb:
> [...]
> 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]
thx
> 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
>> differences:
>> - 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.
Well, I don't have a problem when one of our spec files is being used to
build stuff for Suse or MDK. But *I* don't want to get involved with
maintaining spec files for them because I simply don't know to much
about those distributions and that will IMHO lead to bad packaging
quality. Those people actually using those dist can do that much better.
And I don't want to clutter our specfiles with thousands "%if %{SUSE} do
this %else that" stuff because that IMHO will get quite complicated soon.
Side note: working closely together with package maintainers from other
distribution is IMHO the goal. But that's a different discussion.
>> 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
> ?
IMHO: No.
The repos also have a slightly different approaches here that might be
the reasons for my opinion.
Some repos for example often package the latest version of the software
they offer for all supported dists.
Extras on the other hand ships the latest software often only for the
current dists. Packages for dists in maint. mode normally shall only be
updated if there is a real need to (security problem, major bug)
> Also, for still supported distros : could such packages be split into
> a seperate repo ( CentOSPlus sorts ? ) and then let users make the
> decision ?
That probably know as "Fedora Alternatives" in Fedora-land. It never
started and I'm not sure if that good or bad.
>> - 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 [...]
Why? The rolling release scheme should really stop when a dist goes into
"Maintenance state". We IMHO don't want to build todays or tomorrows
packages for yesterdays dist.
>>> 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,
That's for example a point that's already debatable. ;-) Fedora Extras
Packagers are use to CVS and it would be nice for them to use exactly
the same tools and schemes in this "merged" distro (sure, that's the FE
point of view)
> 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 )
Otherwise agreed :)
>> 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.
I'm not sure, but maybe I'm wrong. dag and dries should comment on this
if a merge is even remotely possible.
> 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.
Sorry, I didn't understand what you were up to here.
>>>> 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
>> here.
> 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...
What do you mean by "start"? Create a new project? Or get the rpmforge
people involved in the packages in FE / EPEL?
> [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.
Sound like this would increase fragmentation even more :-/
CU
thl
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
