On Wed, 25 Apr 2007, Tim Jackson wrote:
Johnny Hughes wrote:
> If RPMforge has a perfectly working ClamAV for EL5, and if we are
> collaborating, why would EPEL build ClamAV?
a) Because EPEL is independent, and should have infrastructure which is
independent of other entities. This is a basic principle of running any
self-contained project. It does NOT exclude collaboration, unless your
definition of "collaboration" is particularly narrow.
EPEL is not independent. EPEL is Fedora is Red Hat.
It does only include stuff that might be tainted in the US to make sure
Red Hat cannot be sued. Red Hat is part of the vision _and_ you endorse
that vision to be part of Fedora. It is not independent.
b) Because the standards, processes etc. of the repos are different
therefore, as we have already established, they are serving different
What is ironic, is that the standards are based on common practices that
all the repositories created as part of the packaging community. I
started using a disttag to mitigate the dependency hell. And we created
common rules in SPEC files even when Red Hat didn't (and sometimes still
The SPEC files in RPMforge are very consistent and do not leave any room
for doubt on how we fix common problems. The SPEC files are even more
strict than what is in Fedora's packaging guidelines.
The clamav indifferences are not caused by a lack of standards and
processes. The clamav package I have was based on the very first clamav
RPM package, newrpms modified it, Petr Kristof modified it and all of
these were compatible. Fedora introduced the incompatible variant.
You see, on one hand Fedora waives with standards and processes, and on
the other hand it caused exactly those incompatibilities even when the
clamav packages did not break any standard or process.
How is that ? Because back in those days, all these repositories existed
and there was communication between them. Before you package a clamav
package you would look what already existed so that they would not break
And back then Fedora stepped in, and redid everything. They could of
course because they made the OS, so they would have authority as well for
the add-on stuff.
I see the same thing happening with Enterprise packages.
And before you say "that's in the past, bury the past and life in the
present". Well, that's pretty hard if the Fedora past has killed the
RPMforge's (and other repo's) presence wrt. Fedora packages and the
Fedora past is repeating itself as we speak. The past is pretty current.
Why shouldn't I be sceptic ? EPEL is introducing packages that break what
is there since 5 years. That breaks my current users. It doesn't even make
sense to report each of these instances because that would keep me busy
until the end of times. Does anyone at Fedora/EPEL looks at compatibility
before they release anything ? No, they put the work on my shoulders.
And you know what, they don't even tag those flagrant incompatibilies with
their own name. Causing even more people to flame me.
So if you thought the repotag was just /me being pedantic, think again.
> Answer to both ... EPEL wants to be "THE" Master 3rd
Party repo, not
> just a 3rd Party Repo. There can be no misinterpreting that, it is just
> plain fact.
As an existing user of various repos including Dag & AT, a tentative
contributor to EPEL (following FE) then I'm still not sure that that's
true and it's definitely not "fact". However, I do believe I understand
why you might feel that way - in fact I had a lengthy and good-humoured
discussion in person with Dag about this very topic at Linux World last
If EPEL is not the Master 3rd party repository, then please start to look
if what EPEL introduces is compatible with what already exists. Because
the clamav packages surely don't play nice with what already existed.
-- dag wieers, dag(a)wieers.com, http://dag.wieers.com/
[all I want is a warm bed and a kind word and unlimited power]