In article <[EMAIL PROTECTED]>, Nathan E Norman <[EMAIL PROTECTED]> wrote: >On 1 Sep 1998, Miquel van Smoorenburg wrote: > : Well actually I am waiting with a new release for inn 2.2 or so .. > >Great! I'm glad to hear this. 2.0 was frighteningly buggy, and I >haven't been bold enough to try 2.1
I'm running 2.1-cvs-current on our production news server right now, and it seems pretty stable (well it has already run 20 minutes ;)) > : I don't want package 2.1 yet, because it still has bugs > : and is not too fast (the overview implementation is a lot slower). > : I've only tested the storage-enabled version sofar, I'm going to > : run the normal version on one news server tomorrow. We'll see how that > : goes. > >You're speaking of CNFS here, right? The CNFS/timehash enabled versions of inn 2.x have a slow unified overview implementation. It looks like if you run it in traditional mode there is no problem as the old overview implementation is used .. but we'll see. > : Also I have to ask the perl maintainer to package the perl shared > : library seperate, so that a perl upgrade won't hose your INN system > : unexpectedly (and force me to release INN in sync with perl). > >Is this also the case if I recompile INN 1.7.2 and enable perl support? Yes.. well .. let me check .. hey, innd was linked statically with libperl. That's less than optimal, I guess, but it does avoid the problem I mentioned above. Hmm it will take a bit more memory and diskspace. I'll have to look into this some more. >I'm interested in recompiling 1.7.2 for a few reasons, namely cleanfeed >and the insync patches. How you managed to do such an excellent job >packaging INN in the forst place is beyond me - it's a complete cluster >from what I can see. Thanks ;). Inn wasn't exactly easy to package .. Mike. -- "Seed me, Seymour" -- a random number generator meets the big green mother from outer space
