[wpkg-users] WPKG with multiple systems and architectures

[Daniel Dehennin]

Rainer Meier <r.meier at wpkg.org> writes:

> 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
>> explain:
>
> 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
answer ;-)

Regards.
-- 
Daniel Dehennin
RAIP de l'Orne