[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:       Jim Conner <jconner83 () yahoo ! com>
Date:       2001-08-20 23:28:27
[Download RAW message or body]

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.  I do think this is 
a very important issue.  Would be nice if KDE could release the source 
tarballs, one binary for Linux, one binary for BSD, and one binary for 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 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 bit more of ram to 
run due to it needing to load libraries that are already on the system, 
albeit different versions.  Until there is some uniformity between distros, 
LSF is working on this, there will be a need for separate binaries for each 
distro and each version of that distro.  Currently, each distro compiles 
their own binaries.  Some are good, some are not.  This can be because it was 
packaged using a full install of the distro and the user only has a partial 
install that leaves out some necessary components.  Therefore the user gets 
dependancy errors when trying to install the latest KDE.  Other problems 
arise when the user hasn't updated key components and libraries that were 
released as updates by the distro.  Most of the problems I've seen in the 
other KDE mailing list by users have been cured by cleaning out /tmp and 
/$HOME/.kde(2)/.  There needs to be a better README for each binary package 
of KDE for each distro/version.  This would include a simple HOW-TO 
installation instructions, a list of libraries and programs that are needed 
and how the user can find out what versions they have and where to get the 
current ones, a list of post-install instructions on how to cleanup from 
upgrading an older version of KDE.  This is done with the kernel source in 
/Documentation/Changes already so they can just 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 popup window telling the user to please 
wait while configuration file is converted.  This would allow the user to 
have a painless upgrade to a new version of KDE without losing all their 
settings and customization.
There are quite a few things that can be done to make upgrading KDE less 
painfull for any user.  Some solutions can be provided by the distro, some 
can be provided by KDE.  I'm not sure that having KDE provide all binaries 
would be a good idea.  This would put quite a workload on a team.  For 
instance, Person A is responsible for binaries of Distro x.y.  They would 
need to keep a pristine install plus upgrades of that distro.  If they custom 
upgraded certain parts, then the binaries wouldn't install for other users.  
Also, they would need rather fast hardware in order for the binaries to be 
compiled on time.  There would also be a need to have a couple of people that 
could also compile KDE for Distro x.y in case Person A had hardware failure 
or was unable to do the task for whatever reason.  These are some of the main 
reasons that distros have decided to compile their own binaries.  That way 
they can make sure that they do get done on time and they are compiled on a 
standard set of libraries.
There are changes that need to be done.  KDE and the distros need to figure 
out what changes to implement and how to implement them.

Jim

On Monday August 20, 2001  5:00 pm, mattc wrote:
> Aaron, Bob, everyone else,
>
> Think for a minute about the commercial viability of a Windows platform
> software vendor who said, "Here is a great program but it doesn't really
> work, and we feel that it is MS's reponsibility to make it work with their
> OS."  How fast can you say Chapter 7?
>
> Now, I'll grant that I have no idea how much work I am asking for in
> getting a viable installer, but it seems to me that someone should have
> picked it up by now and started to look for a team of developers.  Perhaps
> that is what Aaron is actually doing.  If so, I support him fully.
>
> take care,
> Matt

-- 
 
  4:42pm  up 27 days, 17:14,  3 users,  load average: 0.00, 0.00, 0.00
------------------------------------------------------------------------
Running Caldera eD2.4 - Linux - because life is too short for reboots...

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

_______________________________________________
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]