On Sat Sep 27, 2003 at 12:26:16PM +0200, Michael Scherer wrote: > > > can you put exim in contribs at least ? > > > > There's never been an interest before. I've been maintining exim > > packages for about 1.5-2 years now, and I never even knew anyone was > > interested. IIRC, I had asked about putting it in contribs when I > > first built the package (since it wasn't wanted in main) and the > > answer I got then was two MTAs were enough. Never bothered since. > > sorry, i was not here at this time. I should have search the archives > before asking.
It was a long time ago, and wasn't discussed on the list, but internally. You likely wouldn't have found anything even if you had searched. > > If someone wants to put it in contribs, that's fine. I'll still > > maintain it on rpmhelp.net because, right now, you can grab exim for > > 9.0-9.2, and instead of maintaining for "cooker" I maintain for > > stable releases. > > do you think it is some much troubles to maintain it in contribs ? I > mean, this is just rebuilding it in a cooker environnement. And it > doesn't prevent you to rebuild in 9.0-9.2 No, it isn't too much trouble. But, I'm lazy, I have my build systems here, and I don't have to worry about ssh'ing to paris on a slow link. =) That's my primary motivation to keep it here. > > > this will be easier to find it . Dispertion of rpm is not good, > > > this force people to search too much and this gives them bad habits > > > ( downloading semi official rpm ). > > > Putting it in contribs will allow it to be tested by more people, > > > and integrated to cooker. > > > > I disagree. PLF doesn't have a problem with people using their > > packages. > > yes, but plf is bigger than rpmhelp. So? What does that have to do with anything? > if you take a look at easy urpmi, you will see that a lot of repositorie > exist, some of them providing rpms already in contribs, and this is not > easy to keep track of who do what. And i am pretty sure that plf would > not exist if we were able to put the package in contribs. Sure, and by the same reasoning there is a place for rpmhelp.net. Due to licensing problems, we can't put qmail in contribs, and that's what has made rpmhelp.net useful and "known" to people. qmail has only been provided via rpmhelp.net and, let me tell you, that has made it well-enough known for those that require it. > > IIRC, if you were to search in Club's rpm database or > > rpm2html listing or whatever it is, you'll find exim listed under > > rpmhelp.net. > > yes, but, i think we should not encourage people to search rpm on a > website. urpmq and rpmdrake are here for this reason. How can people > choose between your great package, checked with rpmlint, and others > packagers made by alien ? I never said we should encourage them to do so, and at the same token, they can use urpmq and rpmdrake once they setup the rpmhelp.net sources. It's not that difficult... there used to be a djbsupport package in contribs that would setup the source for you.. I removed it because setting up a source is *soooo* easy. > > Are you saying that everything on rpmhelp.net, PLF, Texstar's stuf, > > etc. should go in contribs? > > yes, and no. Texstar is building backport. Plf is for stuff that cannot > go in contribs. I think that a repository than can be put in contribs > should be in contribs , in order to not have the apt-get.org dispertion > effect. rpmhelp.net can't go in contribs. qmail can't go in, so all of the things that depend on it (a large number of packages) also can't go in. The other stuff there (like exim, etc.) are either backports of stuff I personally find useful for my CS2.1 servers or things people ask me to put in. By your own argument, rpmhelp.net cannot go in contribs, so why are we having this discussion? =) > > I think separate rpm repositories that specialize in certain things > > is good. > > It depends on what is the specialisation. But, even if exim is put in > contribs, nothing stop you to provides backport for people who want it. > In fact, more and more people are interested in providing backport , > so, there is a place for a global repository offering sane backport. > But, having it in contribs will give more visibility. And, this is the > first step toward inclusion in main. Of course nothing stops me; it just takes more time. I'm also not desperate to get exim in main. If it goes in, great, it's because it's a great MTA. It's not because I've been lobbying to get it put in. Exim doesn't *need* to be in main. I don't feel it needs to be there and, until sendmail is put in contribs, it won't be there. You try and get sendmail in contribs first... when that happens, I'll put exim in contribs as well and then those interested can work towards getting it put into main as an alternative. > > > And, we will also be able to integrate some tools ( spamassassin, > > > amavis ) more closely with exim. > > > > There really is nothing stopping you from doing that now. It doesn't > > need to be in contribs for that. > > if someone do a spamassassin-exim package, this person cannot put it in > contribs, since it has a unresolved dependancy ( exim ). A package in > contribs can only depend on main and contrib. Sure. But someone can make that same package and send it my way and it will go into rpmhelp.net. =) Besides, I build exim with the sa plugin, so spamassassin should just "work" (never tried, but that is my understanding of it). > now, i fully undestand that you may have too much work to maintains exim > in 2 places. Now you've hit the nail right on the head. =) Besides, how many people would want to use exim? I've *never* heard anyone request using it before, and in fact I only know of one other person who uses my packages. If something is going to go into contribs, I think people should be interested in using it first. I'm not going to put it in contribs if no one wants to use it. -- MandrakeSoft Security; http://www.mandrakesecure.net/ Online Security Resource Book; http://linsec.ca/ "lynx -source http://linsec.ca/vdanen.asc | gpg --import" {FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
pgp00000.pgp
Description: PGP signature
