> Hi Daniel,
> Daniel Dehennin wrote:
>> Thanks everybody for your answers, looking at them I was wondering
>> if having conditionnal variables could be a good thing, let me
> Yes, I will think about this and eventually it becomes part of WPKG.
> However at the moment I have a list of additional features which I
> would like to implement first.
>> I don't really like to have some external cmd scripts, it requires
>> to look at multiple files to see what's happening with a package,
>> what about something like this:
> OK, your decision ;-)
> Personally I like scripting very much. It's extremely flexible and
> allows you to handle almost every situation.
I like scripting too, on sys-admin-friendly platform with
programmer-friendly languages ;-)
> I do not fully agree to the fact that you have to look at multiple
> files. The "install.cmd" script I showed remains the same for every
> installer which as a "common" silent operation. So I don't need to
> debug or look at it as it has proven to work perfectly.
> So the only thing I have to look at is "unattended.cmd" or
> "unattended-uninstall.cmd" which is usually just different within the
> header (command definition, installer selection). So usually I have to
> adapt only two lines within the script to make it usable for any
> application. On the other side this simplifies WPKG package
> definitions a lot and unifies exit codes.
> There is another reason I am doing this which is not related to
> WPKG. I am used to synchronize my whole "software" tree to a memory
> stick. So I take it with me to my customers. Although they do not use
> WPKG I can still go to any application folder and just launch
> "unattended.cmd" and watch the program installing silently. This is
> very handy for support people when you need to upgrade a couple of
> outdated programs.
Yes, that's a good point, I have a script which "extract" <install/>
from packages definition to do the same.
I'll definitely give a try to your cmds before being absolute about my