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

[Dag Wieers]

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 at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]