[Date Prev][Date Next] [Thread Prev][Thread Next]
- From: Tim Jackson <lists timj co uk>
- To: EPEL development disccusion <epel-devel-list redhat com>
- Subject: Re: Collaboration
- Date: Sun, 29 Apr 2007 13:32:20 +0100
Dag Wieers wrote:
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.
You missed my point. I wasn't talking about independence in a
political/organisational sense. I simply meant that it is a standalone
b) Because the standards, processes etc. of the repos are different and
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.
That may well be the case. In that case your beef is (mainly) with the
individual package contributors who either ignored or didn't bother to
check existing packages to see if there was a way to "play nice" before
redesigning a package. This is not a failure, per se, of Fedora, but is
a result largely of human nature, though the project as a whole of
course has to take responsibility. Although we try to present a unified
face, no project would exist without the people that contribute to it.
So, we need to move the discussion away a little bit from "How Fedora
communicates with other repos" and more towards "How the intelligent
people that contribute to Fedora communicate with the intelligent people
that package stuff in other repos". As you rightly imply, no amount of
policies or processes will substitute for good old fashioned
There is however still the fact, as I've pointed out before, that there
isn't always an empirically "correct" answer to a problem. There may be
two incompatible but equally valid ways to package something. That said,
I do agree that in the absence of compelling and observable
improvements, given two competing solutions it would be better to stick
with the existing one for compatibility. I'm 100% behind you on that.
(I'm commenting in general here, rather than specifically about clamav;
whether or not clamav in Fedora is a compelling improvement over clamav
in RPMforge is a discussion for another time).
Actually, due to differing goals, there will probably be times where
there simply is no way to produce one package that meets criteria for
both Fedora and [other repo]. In that case, we may just have to accept
that (and do what we can at a technical level to make things as
compatible as possible, e.g. via Requires/Provides). However we should
all work hard to make those cases as rare as possible, ideally zero.
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 think you're ascribing higher authority and motives here than actually
exist. The problem here is communication, plain and simple. "Fedora"
didn't make the clamav package, a person did. If the clamav packager
didn't look at what other packages were already around, and discuss
possible changes with other well-respected maintainers before making the
Fedora package, then that's regrettable IMHO, and of course I understand
why you, Dag, might feel a bit miffed. (If he did, but the disagreements
couldn't be resolved, then that's a slightly different matter as I
discussed above). I don't think it helps anyone (including Fedora/EPEL)
to reinvent the wheel unnecessarily; we should all be trying to build
the best solutions. Which is exactly why I think collaboration is very
important. To reiterate though, this is a 2-way thing and if a Fedora
packager suggests changes/improvements to you, I would expect you to be
receptive to those in the same way that I would expect the packager to
be receptive to building packages that are compatible with existing ones
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.
On this topic we both agree.
I do understand why you are suspicious of EPEL, and I can't blame you
for that based on some bad experiences with specific Fedora packages.
However, as you can see, I think the views of you (Dag) and me (Tim) are
actually very closely aligned, and whilst I can't speak for other
contributors, it isn't my impression that my opinions are wildly
different to other people's. So that's why I think it would be a shame
for you to dismiss EPEL/Fedora entirely when actually with a small
amount of work from both sides, we can probably reach a solution that
suits everyone. It would be much better to work together instead of
fighting, because then we can focus on the real goal of making packages
that help people get real work done as simply and easily as possible.
We won't always agree 100%, but that's OK as long as we keep the bigger
picture in mind.
[Date Prev][Date Next] [Thread Prev][Thread Next]