[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]