Relationship to existing 3rd party repos/CentOS/SL?

[Tim Jackson]

Dag Wieers wrote:

>> I also think you are over-personalising this by talking about "opponents" and
>> 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 not a 
> 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 aggressive 
connotations than "disagreement")

> Both RPMforge and EPEL provide clamav packages. (RPMforge was providing 
> 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 
on dag.wieers.com) 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 RPMforge...]
 > 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 
root problem.

> 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 
that situation?

> 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 
format :)

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 care 
> 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, it 
> 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 need 
> 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 
issue IMHO.

> 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.


Tim