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

[Michael Scherer]

Mahlzeit.

-- On Montag, 21. August 2006 11:31 +0200 "Bartz, Klaus" <Klaus.Bartz at coi.de> 
wrote:

> 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...
Yes, my requirements are pretty simple.

>> 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)?
a) What is this "maintenance" what you are talking about? Adjusting parameters?
b) No matter if its a 2MB or 2TB installation, either I need/want a backup, 
than I enable it or I don't want one. All of our customers make a backup of the 
installation before updating anything.

>>> 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?
Uhm, that makes backups pretty easy cause every admin knows what that referes 
to in the filesystem. ;-(

>> 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.
Are you talking about an installer or a configurator?
IMHO an Installer (at least its "core") should not fiddle with any 
configurations.
If it needs to do so there's one solution for it:
 custom panels
At least that's the way we are going here.
I implemented a panel that keeps a file (ReleaseInfo.log) up to date, when you 
need to get User-Input I guess there's already a User-Input panel for that, 
isnt it?
Getting back to the (my?) main problem, rolling back such an installation is 
pretty easy too, just make sure you backup the configfile in the Uninstaller as 
well.

=> Should there be an option to just select single files from the 
"Uninstaller"? Sound like we are going to implement a complete backup-solution 
into the Installer.

Something else when it comes to fiddling with configuration and system 
resources.
I bet your software uses a totally different approach of maintaining its 
configuration.
We have some xml-file down in the "etc" subdirectory of our installationpath.


>> 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
And I guess there are many people out the using another pattern for it.
Maybe adding a "VersionHandler" that presents a certain Interface where one can 
code his own VersionHandler against would be an option here.
But handling versions within IzPack for "everyone" is simply impossible and 
therefor IzPack shouldn't deal with it.

> Seems so we have really different requirements where different
> solutions can be used or are required.
Correct.
And we are just two out of ... many. :)

IzPack should just deal with files, not configuration or anything else. If 
theres need for such customized stuff we/you/someone can provide customized 
panels handling such actions.

Your turn. ;)

Greetings,
 Michael



-- 
  I love deadlines, especially the sound they make as they go whooshing by.