[WBEL-users] looking for repositories...

[bishop]

Folks,

Much as I would love to argue the finer points of perl scripts dragging 
in this week's version of the entire family tree of anything remotely 
involved, I can't.  I'm deeply affected by Craig taking my private words 
and dumping them upon you, in direct violation of a portion of RFC1855 
which has never been disputed, and I think I cannot discuss this 
reasonably.  I'm not entirely sure the discussion belongs on this list 
in the first place -- but, then again, I didn't when I replied privately 
earlier, either.

Sorry, and thanks.

  - bish

Craig White wrote:

> Bringing this back on list...
> 
> On Wed, 2005-05-18 at 10:23 -0700, bishop wrote:
> 
>>Craig White wrote:
>>
>>
>>>On Fri, 2005-05-13 at 14:54 -0500, israel.garcia at cimex.com.cu wrote:
>>>
>>>
>>>>Please, Where can I find a list of repositories all over internet.. I
>>>>want to keep my CentOS servers up 2 date with mailscanner, clamAV,
>>>>syslog-ng, and others... I know dag has a very goog one but there are
>>>>some paktes I can not find in dag repository like mailscanner,
>>>>syslog-ng, among others...
>>>>
>>>>Sorry if it's offtopic but I need it!
>>>
>>>----
>>>don't know about syslog-ng
>>>
>>>mailscanner is self-contained, updated frequently and no packagers
>>>bother with it since it is script driven (especially the install). The
>>>rpm's that you download are source rpm's and are basically all perl code
>>>and thus are recompiled by the install script - making it fairly easy...
>>
>>Easy?  Huh?  Pardon me, but that summation really grabbed my eye:  I 
>>don't think it follows, unfortunately.
>>
>>Instead of a single binary package which is installed as part of a 
>>larger *identical* set, this one package needs to distribute source 
>>packages which operators compile onsite and install?  How do we verify 
>>the package contents with our centralized repository if things go wrong? 
>>  How to we push out standard upgrades?  Do we have a (argh) customized 
>>script for that one puny package so that it'll detect and pick up new 
>>source, which is then ~built and installed?
>>
>>Bizarre perversions of packaging - which do not work within the 
>>recognized model are abberations and unusable in any setup involving 
>>more than one computer at a site.  Ugh.
>>
>>Sorry.  Please continue the promotion;  I have 30 machines in a lab to 
>>upgr-oh, right, it's all done automatically via apt because RPMs like 
>>that one aren't in the mix.
> 
> ----
> I wouldn't argue your point - I did insert the word 'fairly' before
> easy.
> 
> unfortunately, not everything of value lends itself to easy rpm and of
> course configuration isn't done by rpm and no doubt that you have
> noticed that the trend is not to do version upgrade of various packages
> that add new features and require alteration of config files. Lastly,
> and this is very much the case with MailScanner, it is a whole bunch of
> perl scripts which have various dependencies and thus have this
> secondary process which rather beautifully scope the perl environment,
> tries to download and compile all of the necessary perl modules to
> provide a proper working environment. With the explosion of all of the
> perl modules on repositories such as Dag, this may not be necessary in
> the future since the perl modules might eventually all be available via
> apt/yum.
> 
> Craig
> 
> _______________________________________________
> Whitebox-users mailing list
> Whitebox-users at beau.org
> http://beau.org/mailman/listinfo/whitebox-users

-- 
	http://www.pvponline.com/archive.php3?archive=20050408
	Because some things are all-the-time jobs!