On Sun, 24 Sep 2006, 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: Let's correct then. > - 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) We do not. We would like to if RPM had the infrastructure for it. But Red Hat is not interested. As a result you can only put 1 SPEC file in a tarball and hope that one works on your distribution (rpm -tb). However we are very interested to work together with other packagers as most of the work is identical. What's more, most of the bug-reports are identical so it makes much more sense to combine the effort for bug-tracking and package-development. (tracing patches, security problems) But now that most RPM community repositories are in control of vendors (see OpenSuSE and Fedora). There is even less interest to join forces. > 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); Our position is that the dependency resolve (yum, apt, smart) should provide the policy that the end-user wants. If the end-user wants to stick with a specific lftp or rsync version than yum, apt or smart should allow that. Yum finally has a protectbase plugin that allows this, although it needs more love to be more useful than it currently is. If you think about that, there are many policies an end-user may have and if you want to accomodate for this on the server-side you'd end up with a repository per package/version. So instead of splitting repositories into one that adds to base, and one that replaces base we think the end-user should be able to configure its depresolver. Of course Fedora doesn't have the issue and maybe that's why it is so hard to comprehend. > - rpmforge builds new packages often for several distributions including > those that are in "Maintenance state" (FC3, FC4 currently); Fedora > Extras is more conservative here What about RHEL2.1 and RHEL3 ? People need a decent subversion for those. If you apply your current rules to the release of RHEL2.1 or RHEL3 you'd be providing subversion 0.19 ad 0.90. Very stable and pretty useless ! What we provide does not have a warranty (and you'd be a fool to provide it) and people have to make up their own mind (and think about the consequences). Rules can't mitigate the problems and risks end-users have on a supported system. At least we provide functionality they might require if they made their own assessement. If you look past RHEL and support, you might look at CentOS. And see that a lot of points vanish. Are you going to constrict CentOS users to a world where support is king and users have to be guided into what they should do ? But that doesn't mean I recommend people to enable RPMforge and upgrade to the latest and greatest. Neither should they with Fedora Extras. Whether it replaces packages or not, there are risks involved installing 3rd party stuff. E.g. if they set up nagios 1.0 a year ago, they may wish to upgrade to 1.4 at their own pace. A repository cannot guide them. And without a way to set a policy in the depsolver they are stuck. Apt and smart are best in this regard as they can hold back updates. I've asked Seth multiple times to consider something like protectbase (or decent pinning support) but Fedora was the place to be and no such thing was useful then. If you think I'm bittered about the state of things, you bet I am :) > > 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. How about diversity ? We will need diversity if you apply Fedora rules to RHEL. > > What is true though is that Dag, Dries > > et al. have achieved an awful lot towards the same goals that the > > proposed EE seems to have. Hence my suggestion that it seems a shame > > not to approach these guys to say "We're hoping to expand FE to > > include packages for other distros, and since you guys are the proven > > leaaders in this field, we'd really value working with you to build up > > the infrastructure, as we are sure your knowledge and experience are > > valuable" > > Well, yeah, that might be a good idea. But note that we try to get > z00dax from http://centos.karan.org/ involved. He AFAIK is in contact > with dag and dries. I'm wondering if the wrong community is involved. To me it makes much more sense if CentOS would be involved and leading the RHEL packaging efforts. Fedora and CentOS users are a different kind (even though some live in both worlds, most do not). And even though it seems pretty easy to rebuild the FC3 stuff for RHEL4 and FC6 stuff for RHEL5, reality is much more complex if you consider that RHEL4 users are still there in 2010. I think the CentOS people have a much better understanding of what is required and what balance needs to be struck. > > I can't believe either "side" can't see such benefits. > > Yeah, but what can Fedora Extras offer them? We are heavily tight to > Core and Red Hat and that heavily limits the things we can offer. That's exactly the reason why I think Fedora is not the right place to discuss RHEL packages. Different worlds, different needs, different policies, different people. > They of course are always invited to join us and I'd try my best to give > them everything we can to make it interesting for them to join us. But I > suppose that's not enough. It's impossible to match both worlds I guess. If you go back to the initial discussions about Fedora, they flat out refused to think about RHEL. Now it's too late, or you have to leave behind RHEL2.1 or RHEL3 (or start all over for these). RPM lacks infrastructure, Red Hat should have backported RPM infrastructure from the very start. RHEL2.1 and RHEL3 is what most companies still use. The company I work for is migrating from RHEL2.1 to RHEL3 because of legacy proprietary applications that are not ready for RHEL4 yet. Kind regards, -- dag wieers, dag@xxxxxxxxxx, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
