Hi Carlos,
I might shed some light on this topic. Although I currently don't have time for
in-dept explanation/analysis.
On 06.09.2012 20:08, Carlos R. Pasqualini wrote:
2012-09-06 14:43:53, INFO : Installing 'LibreOffice' (libreoffice)...
So WPKG is going to verify (check, upgrade/downgrade) LibreOffice. Fine.
2012-09-06 14:43:53, DEBUG : Reading variables from hosts[s]
2012-09-06 14:43:53, DEBUG : Reading variables from profile[s]
2012-09-06 14:43:53, DEBUG : Reading variables from package
'LibreOffice'.
2012-09-06 14:43:53, DEBUG : Got variable 'shortversion' of value
'3.6.1'
2012-09-06 14:43:53, DEBUG : Got variable 'PKG_VERSION' of value '%
shortversion%-0'
2012-09-06 14:43:53, DEBUG : Got variable 'PKG_SOURCE' of value '%
SOFTWARE%\libreoffice\3.6'
2012-09-06 14:43:53, DEBUG : Setting variable: 'SOFTWARE=\\capibara
\repositorio\software'.
2012-09-06 14:43:53, DEBUG : Setting variable: 'SOFTWARE=\\capibara
\repositorio\software'.
2012-09-06 14:43:53, DEBUG : Setting variable: 'shortversion=3.6.1'.
2012-09-06 14:43:53, DEBUG : Setting variable: 'PKG_VERSION=%
shortversion%-0'.
2012-09-06 14:43:53, DEBUG : Setting variable: 'PKG_SOURCE=%SOFTWARE%
\libreoffice\3.6'.
Variables set.
2012-09-06 14:43:53, DEBUG : Install type: downgrade
2012-09-06 14:43:53, DEBUG : Fetched 0 downgrade command(s).
Here's your issue (very likely).
WPKG performs a DOWNgrade, not an upgrade as you might have expected. Please
note that the decision to do upgrade or downgrade is not depending on the
checks. I think you got that point as I have seen you replying exactly this to
another mail in the topic. The checks are entirely there to verify whether the
software is installed properly.
The decision whether upgrade or downgrade is performed depends on the values of
the 'revision' attribute of a package.
So if WPKG now claims it's going to perform a downgrade, then this is because
the machine your package is applied to seems to have already a LibreOffice
package installed which seems to have a newer version (in terms of
revision='...' attribute).
So please verify that your hosts local wpkg.xml in system32 folder does not
contain an entry with LibreOffice where the revision is higher than your package
to be synchronized.
Such things often happen if package manipulations in productive repository
happen while clients do run WPKG or the numbering scheme changes. For example
early versions of WPKG only supported digits in the revision attribute. So I was
used to enter something like "361" in the revision field. Then when changing to
a different format like "3.6.1" it means a "downgrade" for WPKG since 3.6.1 is
supposed to be lower version than 361.0.0 (or 350.0.0 previously installed).
So please compare the revision locally on the host with the one on the server
and you will likely find the cause why WPKG performs a downgrade instead of an
upgrade.
Moreover you will see here that WPKG fetched 0 (in words: zero) downgrade
commands. Likely you did not specify any downgrade commands.
You might also just replicate the upgrade commands as downgrade commands so WPKG
would actually perform the same commands during suspected downgrade. So WPKG
would think it's doing a downgrade while performing upgrade commands. The result
will also be that the checks succeed and finally you are running LibreOffice
3.6.1 on your machine.
Please also note that there were some issues regarding complex variable
definitions recently. I recommend to use latest WPKG version from SVN:
<http://wpkg.svn.sourceforge.net/viewvc/wpkg/wpkg/stable/src/main/resources/wpkg/>
2012-09-06 14:43:53, ERROR : Could not process (downgrade)
Finally the checks fail since no changes were performed to the system (performed
downgrade, no commands, no system change, checks fail).
HTH,
Rainer
-------------------------------------------------------------------------
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
