Dag Wieers wrote:
> I also think you are over-personalising this by talking about
> suchlike. I can (respectfully) disagree with someone, but it doesn't mean they
> are an "opponent".
With opponent there, I meant someone oposing the repotag idea. I am
native English speaker.
OK, I understand. Sorry, I do know you're not a native English speaker
but your English is so good that it's easy to forget :)
("opponent"/"opposing", to me, has considerably stronger/more
connotations than "disagreement")
Both RPMforge and EPEL provide clamav packages. (RPMforge was
them long before Fedora introduced them, but that's just history). Sadly
Fedora introduced them completely different. Some subpackages are
different in aim and content.
Actually, this is a very interesting example to me. I have a
considerable interest in e-mail handling and virus/spam scanning, and
have written some documents and given talks about this topic. (My guide
"Spam & Virus Scanning with Exim 4.x" has been downloaded tens of
thousands of times over the past 4+ years since I wrote it). I was quite
an early user of clamav, and created an RPM very early on (I think even
before you, because when I first wrote the spec I'm pretty sure I looked
) and definitely before Fedora. I published the
specfile on my website and referenced it in my HOWTO. I had many
requests about the clamav packaging, even going so far as to install
OSes that I don't normally use to help people build clamav RPMs.
Eventually, clamav packages were introduced by you and (later) Fedora.
Now, even though I had already deployed clamav on my own machines and
referenced it in documents, I decided to change my servers and documents
to refer to the Fedora packaging instead, not because I liked the
packaging better, but because I think Fedora is a good project and I
want to encourage it. So I put the project higher than my own personal
preferences, even though I had to do extra work. (And actually it saves
me work in the end, because I don't maintain clamav in Fedora)
Without a repotag you get:
[...differing packages in EPEL and
How would Yum (or a user manually) make sense of this ? Packages may
resolve to the wrong thing, but you don't know what is what because
there is no unique identifier to match it with.
OK, so this is not a great situation I agree. But the point here is the
problem is more fundamental than repotags or not. The real problem is
collaboration, not repotags. And here's where my point about
"co-operation at grassroots" comes in. Because what would ideally be
happening here is that the Fedora clamav maintainer, and the RPMforge
maintainer (you, if that is you) have some private discussions to agree
a common package structure. Then there is no problem, repotags or none.
OK, so in some circumstances people will never agree. But generally it
seems to me that most packagers have similar goals and most people are
open to suggestions.
And my original point was that you can't legislate for that kind of
co-operation at a high (EPEL) level. It needs to be more personal than
that. I do understand how repotags might help users to visually
differentiate packages in situations like this, but in my personal
opinion that's only a very small advantage, which is why I really don't
have strong opinions about it. The real issue is trying to address the
I can hear 2 things now: 'than don't drop the rf repotag'
As I said, anyone saying this from EPEL is being hypocritical if they
voted against inclusion of repotags in EPEL. But is anyone actually in
and 'another argument for not mixing repositories'.
Well, this is kind of true, but you're right in that it's missing the
point - it would be better if we just collaborated and adopted a common
The question is: if some Fedora packagers were prepared to change their
packages to be more like RPMforge, would you be prepared to change some
of your packages to help the higher goal of cross-repo compatibility?
How about even when you think your packaging is OK? If so, great! If
not, then what you call "3rd party compatibility" is really just a 1-way
thing. Nobody's forcing you to collaborate with EPEL, but by the same
token you can't complain about a lack of co-operation if you don't.
Not addopting a repotag is saying to other repositories, we don't
about diversity. We are the one big repository that will rule everything
and either you join or we'll crush you.
Again, like Axel, I think you're finding political implications that
simply aren't there. I didn't vote but if I did, I would probably have
slightly erred on the "no repotag" side. But that would **not** be
because I had the highly-charged opinion above. It would just be that I
didn't think there was a strong enough reason to use them. No disrespect
to you or others or intention to "crush" your efforts - just a
"professional disagreement". I think what you're doing is great (heck, I
use some RF packages and I've even sent you a couple of small patches
before now), and as Thorsten said, the goals of RPMforge and EPEL are
different. But I just don't take the view that "without repotags,
co-operation is impossible".
As I said to Axel at the start of this thread, you obviously have strong
opinions about this issue, and I respect that. But I think you would be
making a mistake to misinterpret other people's disagreement as meaning
that they hold equally strong opposing opinions.
You have a long history with RPMforge; you are absolutely right that
EPEL is a "newcomer". You're rightly proud of what you have achieved,
and I think as a packaging community we have a lot to thank you, Axel,
Matthias and others for. However, that doesn't mean that everyone will
always want to follow the same policies as you. More importantly, even
when they disagree, it does *not* mean that they intend any disrespect
or ill-intent towards you.
Not adopting a repotag is saying to users, hey, if you have problems,
is all your own fault. We told you not to mix repositories. You should
stick to ours.
This is just an opinion; personally I don't get that connotation.
And you know what, in contrast to Fedora, with EPEL there is a clear
for the diversity. Should I stay with a specific version, or do I require
the new functionality ? You can't have both in a single repository. Yum
can't handle it.
Well, there is "includepkgs" which I personally find very useful, but
again I'm trying to avoid rehashing the repotag discussion. Your
general point is very good, and very important, and looking at the
general picture of repo collaboration this is something that we should
all be very aware of. Indeed, as I mentioned before, this is something
that I am very conscious of: for example I have a lot of CentOS 3/4
boxes, but there are some applications where I *need* newer versions of
packages. So I have my own repository with newer packages in, just like
RPMforge. This is why RPMforge and EPEL serve different needs and why I
personally think that we SHOULD collaborate as much as possible, and
have as an ideal goal the ability to mix repos without destroying
systems. But again, this is a mostly a per-package personal co-operation
Not having repotags makes it harder for users. But this is not about
users, this is about politics and power plays.
??? I really don't see the "power plays" here.
As a newcomer there is an
interest of making the situation harder so that people move to EPEL.
If there is anyone participating in EPEL with secret agendas like this,
I would personally appreciate it if they would make themselves known
and/or go away. I don't see any need for such self-serving behaviour.
I'm actively interested in EPEL but I definitely have no such agenda,
and from my reading of the lists I have not noticed any obvious agenda
like that amongst others (even those that voted against repotags).
Collaboration is good, but so is diversity: a wish to see EPEL succeed
definitely does *not* necessarily imply a wish to see other projects fail.
Again, in the absence of compelling evidence to the contrary I think it
would be a mistake (and probably rather uncharitable) to equate a
specific disagreement on one technical issue with a malicious agenda to
crush other repos. I think most (hopefully all!) people involved here
are just trying to do useful stuff and make things that are easy to use.
We might disagree about *how* to do that from time to time, but that's a
world away from actively destroying each other's efforts.
Please do consider putting some of your suspicions behind you and
joining in. It would be great if you were on board with EPEL. Nobody can
promise you that they will always agree with you, but what we can do is
jointly try to find some positive, constructive solutions to the
problems that exist, like making packages more compatible.