Tranquil IT Forum

Good morning,

In package y, I need to use the WAPT.download_upgrades() method to update another package x (upgrade to version n+1 of package x installed in version n) and then install it with WAPT.install(x).

However, this doesn't work. During the installation of package y (no error, the package installs correctly), the machine doesn't download the latest version (n+1) of package x and therefore doesn't install it. It remains with version n of package x. I don't understand why, given that version n+1 of package x is available on the WAPT server, and that the machine's agent is correctly configured to retrieve packages from the WAPT server. It's not a problem with the maturity of package x either (the problem occurs regardless of its maturity). Furthermore, if I select the machine in the console, then click "Check for updates" and select "And download packages," the machine does download version n+1 of package x. (Below, this "package x" is "col73-xmind"; I want to update and install it within the installation of another package.)

Here are the corresponding lines of code: These same lines of code worked before (I already did it this way with another package a year ago without any problems)

Where could the problem be coming from?

I added a few lines of code to perform checks, and indeed, package x is found in version n (actually 16), but strangely, version n+1 (actually 17) available on the server is not seen, downloaded, and installed, according to the log. Instead, wapt re-downloads and reinstalls version n (16) as shown in the log below.
However, as stated in my previous message, when I check the package updates for the workstation using the console and download the packages, the workstation does indeed see and download version n+1 (17)!?
Below is the installation log for the col73-xmind8 package, which contains the preceding lines of code:

package col73-xmind detected,
installed xmind wapt package version=16 - attempting to update package"
col73-xmind_3.7.2.0-16_windows_0f4137ed1502b5045d6083aa258b5c42_PROD_9757a8c0d5a4e8d25c3a08543880461d.wapt: 262144 / 161672722 (0%) (15.62Mb/s)
col73-xmind_3.7.2.0-16_windows_0f4137ed1502b5045d6083aa258b5c42_PROD_9757a8c0d5a4e8d25c3a08543880461d.wapt: 68419584 / 161672722 (42%) (64.22Mb/s)
col73-xmind_3.7.2.0-16_windows_0f4137ed1502b5045d6083aa258b5c42_PROD_9757a8c0d5a4e8d25c3a08543880461d.wapt: 138936320 / 161672722 (86%) (65.72Mb/s)
col73-xmind_3.7.2.0-16_windows_0f4137ed1502b5045d6083aa258b5c42_PROD_9757a8c0d5a4e8d25c3a08543880461d.wapt: 161672722 / 161672722 (100%) (65.78Mb/s)
Installing XMind
Installing: xmind-8-update2-windows.exe (3.7.2.0)
Copying the XMind folder (AppData) to C:\Sources\XMind for future installation...
Copy completed successfully
Installation completed successfully
Copying the XMind8 portable application folder
Installed xmind wapt package version=16

Good morning

If I check for package updates for the workstation by downloading the packages, the workstation correctly sees and downloads version n+1 (17)!?

So in the code you're doing an update? WAPT.update()

Hi Simon,

No, I hadn't used WAPT.update() before.

Doing it before WAPT.upgrades() makes it work now, thanks!

Regards

Hi Brice,

you should be careful to avoid using `download_upgrade` or `update` in an `install` function, because in many cases, when the machine shuts down during installation, there will be no network connection (VPN, Wi-Fi, 802.1x, etc.), and the download, and therefore the installation, will fail.

Regards,

Denis

Indeed, it's better to put the second software as a dependency of the first in the control file; it's much cleaner and less prone to problems.

Hello Denis and Vincent,

Thank you for your advice. This case is a bit unusual. Actually, I can't and don't want to make this package a dependency because it's a misnamed package whose uninstall() function doesn't work (error) and which can't be uninstalled as is. So I want to replace it with another package, y. Therefore, I'm using WAPT.update() and WAPT.download_upgrades() to update the faulty package, and in this same replacement package, y, I uninstall package x later after it's updated using WAPT.remove(package x), since package x's uninstall function is then working.

I've already removed this package from all machines, so it won't be reinstalled once the uninstallation is complete.

This allows me to automate its replacement when installing the new, correct package. In any case, it would be far too tedious to have to manually uninstall package x on hundreds of machines after an update (the machines also need to be powered on for this to work). So I'm taking advantage of the installation of the new replacement package to automate this. I already did this a year ago with another package that had the same problem, and everything went smoothly. On hundreds of machines, there were no issues downloading the new version of the package. The download is then performed from a secondary repository on the local network.

But I thought that when the system shuts down, waptexit started downloading updates before installing them?!

Regards,
Brice

But I thought that when Waptexit shut down, it started downloading updates before installing them?!

No, everything must have been downloaded before launching waptexit because we cannot know the network availability status when the machine is shut down.

What you could have done, now that we know your use case better, is to correct the uninstallation function of the dependency package, push the correction first and then it would have worked well I think with an additional correction to the "control" file of your main package with a "depends: newpackage" and a "conflicts: oldpackage".

Hello Vincent,

What you could have done, now that we know your use case better, is to correct the uninstallation function of the dependency package, push the correction first and then it would have worked well I think with an additional correction to the "control" file of your main package with a "depends: newpackage" and a "conflicts: oldpackage".

Indeed, that seems possible. I thought the machines would remain in error mode because if the new version of the package hasn't been updated by the machine, then its prior uninstallation (via the conflict) will fail, and the new replacement package won't install but will instead return an error. Thinking about it, it should only be temporary, actually, until the machines update the package whose uninstall function is faulty.

The uninstall function can be fixed with a newer version of the package, which is simpler and more reliable than what you're trying to do.

The main thing is that you're able to do what you want with WAPT.