Re: [platform-update-dev] Comment on Installation and Update Draft: Usin

[klicnik@xxxxxxxxxx]

Peter, thanks for the comments. We'll look at the issues you raise and try 
to reply in terms of 2.0 and future direction.

This whole update support excercise has been a long series of compromises 
between mapping to multiplicity of native installers with different 
supported features/ packaging structures, and providing dynamic/ web-based 
updates to Eclipse "components".  The difficulty seems to be in striking 
the right balance between the two in a way that makes sense for an open 
source project.

Please respond to platform-update-dev@xxxxxxxxxxx 
Sent by:        platform-update-dev-admin@xxxxxxxxxxx
To:     platform-update-dev@xxxxxxxxxxx
cc: 
Subject:        [platform-update-dev] Comment on Installation and Update Draft: Using 
Native installers.


Over the last 20 years installation mechanisms have become more and more
mature. They have worked towards reliability, stability of the platforms
they work on
and aid in supporting and maintaining the products they install. Even
Windows has finally caught up with the rest of the world and has realized
that randomly
placing files with basically unzip and a registry entry makes systems
difficult to maintain and has with the advent of Windows 2000 introduced
Windows Installer.
The suggested method of allowing eclipse to install the files is a major
step backwards.


All the "supported" in V20 operating systems  have installation programs:
Windows: Windows Installer
AIX:  installp
Linux: several but RPM is the most common.
Solaris:  pkg cmdset  "pkgadd to add a new package etc

These installation programs all have several things in common
  a) a database which knows what is "officially installed" and where it is
  b) what dependencies are required and available
  c) the ability to install/uninstall with some logic defining whether is
OK to do so.
  d) have hooks which the install developer can use to implement c) above
     - usually pre,post install and pre,post uninstall
  e) they can apply updates/patches to the installed software.

Not using native installers in most cases is a bad idea for several
reasons.
1) They can determine if your system has the necessary software needed to
install  (i.e prereq checking)
               Example:  I have DB2 6.2 installed my new handy dandy 
plugin
"requires" no less than DB2 version 7.3.
                                   I use the update manager which has no
clue and my plugin is broke out of the box.
2) System admins have custom install setups to administer multiple 
machines
at once. They shouldn't have to retool just because eclipse is not using
the standard installers. (You see more of this on the mature systems like
AIX,Solaris HP-UX)
3) Most systems install to read-only directories. Especially if they are
multi-user systems. The platform installer cannot download into this
location as the platform
   itself needs to be installed with an installer tool. If you do so at
uninstall the uninstall will fail.
4) Some systems  "require" all software to be installed with the installer
in order to get support. For example an IBM product cannot ship on AIX
without using installp for installation and patches.


It isn't necessary to reinvent the wheel here.

Eclipse should be providing hooks which the install tools can use to
validate the install:
The install tools can then ask eclipse
1) is it ok to install this?
2) is it ok to un-install this?
3) is it ok to update this?
4) is it ok to lay this down side/side
5) configure yourself i have laid some stuff down over here and here
6) these have been removed. configure yourself

There are 3 main issues with install/update for eclipse as I see it (if 
you
have more just shout i probably missed some):
1) Looking for and getting new updates/patches
2) laying down the files on the filesytem in a way the operating system
approves of an which can be maintained.
3) configuration of eclipse when new files are added/removed

Eclipse should only be concerned with #1 and #3 above installing the files
to the filesystem is the job of the system install tools.

For WSAD at least on linux and most likely on Windows all
installation/service/updates and installations will be using the native
installers. Since the update mechanism draft states basically there is no
support for this beyond it allows it and then will ignore it I can't see
much reason for having an update manager at all.

Thanks,
_____________________________________
Peter Manahan
WSAD Linux Port Team
VisualAge for Java Release Lead
manahan@xxxxxxxxxx
_____________________________________

_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev