[izpack-devel] Backup for the installed files and the wipeAbortproblem

[Bartz, Klaus]

Hi Michael,
OK, it seems so, that you do not need maintenance. It is possible
to implement an update mechanism for your requirements which works
fine for you. May be it will be not enough for my requirements...

>So uninstall just a pack isn't possible. Solution is to roll back 
>completely and install again with
>the right packs selected.
>I don't see a problem here.

There are customers which knows MSI and asks why our installation
do not support maintenance. What do you would do if the program
creates many data (many means TBs)?

>> E.g. I think there should be a data base independant from one
>> installation to store e.g. what packs are installed in what
>> version etc.
>Uh oh, what do you mean with "independent" from an installation?
>Sounds like "pack some stuff in the registry", which isn't available 
>everywhere.

On principle it is marginal where data are stored. If possible
I will delegate this question to the VM. Why not use 
java.util.prefs.Preferences?

>An idea here would be to have a "versions.db" file in the uninstaller subdirectory to
>save such data. Which would be installation/application dependant which is what it
>should be IMHO.

Yes, if your application uses no system resouces. At the point
it uses e.g. ports, a dependant database is not enough. State of fixed
ports you should check. This will be not always trivial. If you need
more than one installations of your product of one machine and if you use
dynamic ports it can be necessary to calibrate both applications.
This is not a pipe dream else reality for some applications.

>Using the word "version" raises the next problem, what pattern 
>do you use 
>for versions?
>1.0? 1.0.1.2?
>
>We use something like <release>-<patchlevel> here which looks like 
>"JUL06-02".
>July-2006 release, patchlevel 2.

Oh yes...
We use only numbers (and at some points chars for fun like Oracle), 
no dates for identifying our version.
<major release>.<minor release>.<patch>.<hotfix>
e.g. 1.4.001.003

Seems so we have really different requirements where different
solutions can be used or are required.

Cheers

Klaus