[wpkg-users] packages not installing/upgrading

[Carlos R. Pasqualini]

El jue, 13-09-2012 a las 07:42 +0200, Stefan Pendl escribió:
> Am 12.09.2012 22:07, schrieb Carlos R. Pasqualini:
> >>
> >> What does the number after the hyphen mean in your version number?
> >>
> >> x.y.z-a ... what means "a"?
> >
> > i reserve the last value for reviews of the .xml file with the same
> > version of the installer.
> >
> > suppose i have a 1.2.3 version of the package, i'll create a 1.2.3-0
> > revision of the xml, and if i found something wrong in the XML file, i
> > can create 1.2.3-1 ... 1.2.3-9 without having trouble with the possibly
> > upcoming version 1.2.4 of the package.
> >
> > It's just used by me.
> >
> > ¿do you think it's bad to do that?
> >
> 
> I have done so in the past too, but am now adding the additional version 
> part with a dot, since the hyphen gave me some unexpected results.

OK! i will take your advice right now!

> >>
> >> In general this should be solvable by using:
> >>       <downgrade include="remove"/>
> >>       <downgrade include="install"/>
> >>
> >
> > i this particular case, i do not need to execute remove before install,
> > because i'am not really downgrading, i'm upgrading but WPKG thinks i'm
> > downgrading, apparently there was an error in a previous version of the
> > xml file (i'm trying to understand what have happened).
> >
> 
> Can you post the package as it is contained in the file 
> "%SystemRoot%\System32\wpkg.xml" on the failing system and how it is now 
> defined on the server?
> 
> If we compare those two we can better see what is going on, since that 
> is the thing WPKG.js compares too.

This is the portion on Libreoffice in the file %SYSTEM32%\wpkg.xml of
one of the affected machines (before the downgrade definition):

 <package id="libreoffice" name="LibreOffice" revision="%PKG_VERSION%"
reboot="false" priority="10">
  <variable name="PKG_VERSION" value="%shortversion%-0"/>
  <variable name="shortversion" value="3.5.4"/>
  <variable name="PKG_SOURCE" value="%SOFTWARE%\libreoffice\3.5"/>
  <depends package-id="java7"/>
  <check type="uninstall" condition="versiongreaterorequal"
path="LibreOffice .+" value="%shortversion%"/>
  <install cmd="msiexec /qn /i "%PKG_SOURCE%\LibO_%shortversion%
_Win_x86_install_multi.msi" ALLUSERS=1 CREATEDESKTOPLINK=1
REGISTER_ALL_MSO_TYPES=0 ISCHECKFORPRODUCTUPDATE=0
REGISTER_NO_MSO_TYPES=1"/>
  <upgrade include="install"/>
  <remove cmd="msiexec /qn /x "%PKG_SOURCE%\LibO_%shortversion%
_Win_x86_install_multi.msi" "/>
 </package>

After obtaining this copy, i have updated the package definition with:
<downgrade include="install" />
and now i have 3.6.1 on the affected machines that i have tested (around
half of the total i know had this issue). I'll assume (by now) that this
issue is fixed.

> 
> > By the way, i have no way to know all the remove commands for every
> > package's version; as i understand, i cannot use the remove command of
> > other version of the XML package because it will call the remove section
> > of the current version of the XML package, not the remove section of the
> > installed version of the package; to call the remove section of the
> > installed package, i need to remove the package from the profile.
> >
> 
> Generally I use the MSI file for remove too, since I really don't like 
> and need to bother with the application IDs.
> I don't know why users spend so much time on finding out the application 
> IDs, when there is a simpler solution.
> 
> Nowadays MSI files are able to remove older versions of the software too.
> 

ohh... i didn't know about that, i will test it!


Thanks Stefan!