[wpkg-users] [Bug 260] Feature Request - WPKG to automatically create variables

[bugzilla-daemon at bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=260

--- Comment #4 from Rainer Meier <r.meier at wpkg.org>  ---
I still believe that option 1 (hard-coding such variables in WPKG) is the worst
out of all. I am not even saying that it would be hard to implement, but not
everything which can be implemented does make sense.

In the initial request there were already some sniplets provided which are
samples of variables like PKG_DESTINATION which is pointing to the 32-bit
program files folder on 32-bit and 64-bit installations.

These sniplets can easily be added to the host or profile definition to make
them globally available to all packages. So it's not true that you would have
to repeat them over and over again in all packages. Placing them in one single
location (profile I recommend) would be absolutely sufficient.


Such variables are always specific to a target environment and for me it just
does not make any sense to hard-code them in WPKG in order to enforce specific
variable names (which might also collide with some existing installations).
Moreover there will be an almost infinite list of "helper variables" one could
think of. If WPKG starts to implement some of them we will have to release WPKG
more frequently just to update variables which happened to come to the mind of
some WPKG user just because he thinks it's useful or he might use in more than
one package. One more reason would be language-specific variables as they are
required for example to support the location of the public start menu location
on different languages. As WPKG itself is language-neutrally implemented in
general it would have to be extended for every language. If not, then users
will start to complain that in their environment %STARTMENU% does not work
while for others it's working perfectly, just because a specific locale edition
uses different folder names. So I still believe adding such variables to
profiles or hosts is much more efficient.

Maybe supplying some example profiles with generic global variables might help
assisting users on the idea of profile variables.

-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.