[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Redhat 7.1 and KDE2.2 are go! - But not for everyone
From:       Steve Hunt <theshunt () crosswinds ! net>
Date:       2001-08-21 11:48:10
[Download RAW message or body]

On Monday 20 August 2001 07:56 pm, Aaron J. Seigo wrote:
> On Monday 20 August 2001 17:28, Jim Conner wrote:
> > Well, the KInstaller project has been mentioned.  Also, Loki has an
> > Installer that they use for their games.  I think it's GPL or some such
> > license.  I remember hearing either earlier this year or late last year
> > that InstallShield(main windows installer) was ported to java.
>
> there is also kdeinstaller in kdenonbeta, but kinstaller looks to be much
> further along. loki's installer is based on gtk+, and i'd much rather see
> an installer that looks at home on kde. i don't think java is a good
> solution either (if InstallShield would even work very well on linux.
> anybody tried?)

If you remember, KDE Installer had a lot of publicity.  In fact, I well 
remember the night when I was working on their website (yes, I'm responsible 
for the ugly design ;-)) when I was working on the page, KBiff told me I had 
mail, and in the /. mailing list, it mentioned the KDE Installer site.  Doh. 
Error403 (Nick Betcher) who was the creator of KDE Installer ran his own 
server, and it was /.ted.  Memories.

However, he said that he had stopped work on KDE Installer due to lack of 
interest.  He was on /. as well as every other news site under the sun, and 
he couldn't get much help at all.

But, here are some problems with the idea of a KDE Installer.  First of all, 
KDE Installer was GUI oriented, which is great for upgrading KDE.  But, if 
you don't even have X, things could get a little more interesting ;-)

Second, every distribution scatters files in different locations, so an 
installer would need to pay attention to this.

Also, the package managers.  What would we do with that?  Would we have the 
installer compile every package and install it into the default spot?  If we 
did go with a package manager, it would be distro-specific, and that would be 
kind of a drag for anybody with an unsupported distro.  But, if we made it 
compile/install on every computer, during an upgrade from the ver. of KDE 
that came with the distro, it could put files in incorrect locations.

Isn't that sort of the problem with Linux/UNIX?  There are so many variables, 
so programs don't play nicely together like they do on other standardized 
platforms.

So, I thought I'd just add a quick idea that might be unrealistic, but worth 
thinking about: our own Linux distribution.

Just a thought.

>
> > Unix. The problem is that each distro is released with a different set of
> > libraries that the binary needs to be compiled against.  The way other
>
> not to mention different paths ...
>
> > projects have gotten around this is to release a static and dynamic
> > binary of their source. Unfortunately, a static binary of KDE would need
> > quite a
>
> a static build still wouldn't work since the C++ ABI varies from distro to
> distro depending on the version gcc installed. within the next 2-5 years
> the C++ ABI on all gcc platforms in use will probably be uniform (due to
> gcc3).
>
> > use a similar format. Just had a thought.  User X upgrades KDE2.x to
> > KDE2.2.  For example, KMail has changed format of it's config files and
> > breaks when loaded because user hasn't removed /$HOME/.kde(2)/.  Wouldn't
> > it be easier if when KMail loaded, it recognized the older config file
> > format and converted it to the new format?  There can even be a simple
>
> this is a very good idea, so good in fact that there is already such a
> facility available (since 2.1) that allows upgrading config files ... as a
> bonus it doesn't require adding useless cruft directly into the application
> in question to check for older config files every single time it is run.
>
> one of the common problems w/config files in total corruption. this will
> hopefully be largely fixed when KConfig gets some checksumming capabilities
> (which it apparently is according to some devel discussion last month).
> KConfig will be getting some large-ish overhauls for kde3.
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability

[prev in list] [next in list] [prev in thread] [next in thread]