Upgrading KDE 2.2

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Kurt Granroth
Date:  
Subject: Upgrading KDE 2.2
Eh? What does scripting or SPAM have to do with the replied-to message?

On Wednesday 22 August 2001 09:14 am, Kimberly Secor wrote:
> Dumb question #2006.
> Since all of you know scripting, why can't you create scripts that look for
> key phrases(not just words) to filter SPAM. Surely, this can be done.
>
> Anyone doing it?
>
> Kimberly Secor
> Account Manager
> 480-368-4638 ext23
> www.extremezone.com
> Extreme Internet is Ranked 2nd on The Business Journal's THE LIST for 2001
>
>
> -----Original Message-----
> From:    John (EBo) David [SMTP:]
> Sent:    Wednesday, August 22, 2001 9:02 AM
> To:    
> Subject:    Re: Upgrading KDE 2.2

>
> Kurt Granroth wrote:
> > Kurt Granroth
> > KDE Developer/Evangelist
>
> Well brother Granroth (sorry, I couldn't resist the playing with the
> Evangelist twist ;-)
>
> Well, met and thanks!
>
> > If you are compiling from source, then this should give you a good hint:
> >
> > http://www.kde.org/install-source.html
>
> Thank you, I'll go try that.
>
> > If you are installing from binaries, then no, there isn't. Each vendor
> > is free to package KDE in whatever way they see fit so some have
> > dependencies that others don't.
> >
> > The package policy, though, is to have it so *all* dependencies can be
> > satisfied either with packages on ftp.kde.org or on the CD-ROMs. You
> > should *never* have to go anywhere else to satisfy a KDE dep. Although,
> > I have heard rumors that Mandrake and maybe RedHat might be requiring
> > stuff from Cooker/Whatever which is very bad (if true).
>
> I was looking to upgrad an old distro, so it is likely that fishing
> around for the RPM's will be a nightmere (and I cannot afford to spend
> the time at the moment), so I think I'll go with the source option and
> stuff all the binaries in something like /opt/kde2.2 or some such. That
> way I do not clobber my existing set up...
>
> But this whole situation rases the problem that having a user base that
> is several million strong (or however Linux and GNU is at this point) I
> wonder if there is some way to set up the dependencies such that
> multipul can be set up to coexist (and I mean really coexist). Not
> having spent much time thinking about it and just writing off the cuff,
> I think this would require at least a general solution to the dynamic
> library linkage that could deal with linking/loading against .so's of
> specific revisions AND allow multipul older version to be able to
> resolve... Anyway I need to get to doing real work so catch ya'll
>
> EBo --
> ________________________________________________
> See http://PLUG.phoenix.az.us/navigator-mail.shtml if your mail doesn't
> post to the list quickly and you use Netscape to write mail.
>
> PLUG-discuss mailing list -
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
> ________________________________________________
> See http://PLUG.phoenix.az.us/navigator-mail.shtml if your mail doesn't
> post to the list quickly and you use Netscape to write mail.
>
> PLUG-discuss mailing list -
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss


-- 
Kurt Granroth            | http://www.granroth.org
KDE Developer/Evangelist | SuSE Labs Open Source Developer
         | 
            KDE -- Conquer Your Desktop