[wpkg-users] packages not installing/upgrading

[Rainer Meier]

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