http://bugzilla.wpkg.org/show_bug.cgi?id=209
Rainer Meier <r.me...@wpkg.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |r.me...@wpkg.org
--- Comment #1 from Rainer Meier <r.me...@wpkg.org> ---
I am not sure if I get this request correctly. So let's ask for some more
detail...
First of all using a variable in the "revision" attribute in the package is
often not a good idea. However if you do it I strongly recommend to use
variables which are defined within the package itself. Not a variable from the
profile or host definition. The reason is simply that the variable will expand
at RUN-TIME to its value. Host and profile variables however are always read
from the server host/profile definition (there is no local storage for
host/profile definition).
Moreover you need to know that WPKG will NOT modify the package definition when
it's written to the local wpkg.xml. So in your example you will see
revision="%PKG_VER%" in your local wpkg.xml. As a result if you define PKG_VER
in your profile then PKG_VER of the local package will also resolve to the new
variable. So basically the package never gets updated as the server-side
package will always resolve to the same value (PKG_VER).
Now when writing about it I guess I know what you're about to do. Perhaps you
would like to upgrade the revision for one single package inside one profile
while keeping the revision at an older number for another profile. In general I
would treat this as "bad practice" as you would assign the same package using
different package revisions on different hosts. Maybe you also misunderstood
the purpose of the "revision" attribute. It's not meant to be synchronized with
the software version but rather to track changes on the package definition. So
I would consider it to be dangerous to specify the revision of a package
outside the package itself.
Fulfilling the request would require the following:
During installation the PRG_REL variable in "revision" attribute would have to
be resolved and hard-coded to the value it got during installation. As said,
currently WPKG policy is that the server-side package definition is copied to
the local wpkg.xml without any change. Moreover it would replace a variable
with a hard-coded value which might have negative side-effects on existing WPKG
configurations.
So the variable substitution within the revision attribute was introduced in
order to allow using the revision number in multiple commands and the revision
without having to hard-code it in multiple locations.
--
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
_______________________________________________
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
