Dear Kent,
You are very fast in responding.
answer 1:
Indeed we are trying to use same code for all KiXtart distribution, but
it doesn't mean we can't handle both method. A good example is how we
are doing it for debugging with the kixstrip tool. This tool handles
all versions and it can and will latest functions of your kixtart
version for collecting some information about your kixtart client
environment.
Your point is, that by using $os=@producttype as code no spe-
cific upgrade is necessary for new KiXtart 4.x releases.
Of course we will wait for some reactions on the latest distributions.
Of course we will implement this.
(TO_DO)
answer 2:
Of course we doesn't need debugging in production, but when some-
thing is going wrong during running one of our packages it can be
very hard to find out what is going wrong.
Simply by creation of the environment variable kix-debug befo-
re running the installation will create for us a very useful file
for further analysis. Also for administrator it can be very handy,
when something is going wrong. Something which isn't directly re-
lated to package but more to the client/network/server environment.
For the same reason we have introduce a control file, which shows
in a compact way "how was the installation be done".
We hope we give some clearness about why. A normal user doesn't
see it. A normal user simply runs a package withoutcreation of
any environment variable.
We prefer to pass a parameter by the package call, but iexpress
doesn't expand such parameter. For us it was the only solution
to have influence on installation process.
answer 3:
Possible something from one of those first releases. We will take
a closer look on it "when was it introduced", "can it be made shor-
ter or were there special reasons for this format".
(TO_DO)
greetings.
