Autoremove packages are removed unnecessarily before update

[VitosX]

If a package (install.pkg) has autoremove key set to true in its' pkginfo file, and a newer version of this package is available for installation on a client, managedsoftwareupdate performs removal of the old package before installing the new one. It has no point.
Affects v6.2.1.4545.

[Greg Neagle]

Can you provide steps to reproduce this behavior?

[VitosX]

Sure.

1. Prepare two versions of some package. For example let's download autopkg-2.7.1.pkg and autopkg-2.7.2.pkg from https://github.com/autopkg/autopkg/releases.
2. Import autopkg-2.7.1 into repository using munkiimport 6.2.1.4545, all defaults (name: autopkg, catalog: testing)
3. Add autopkg to managed_installs in the test client manifest. Run makecatalogs.
4. Run managedsoftwareupdate 6.2.1.4545 on the test client and install autopkg.
5. Import autopkg-2.7.2 into repository. Add autoremove key and set it to true. Run makecatalogs.
6. Run managedsoftwareupdate on a test client.

The result:

Managed Software Update Tool
Copyright 2010-2023 The Munki Project
https://github.com/munki/munki

Starting...
Checking for available updates...
    Preventing idle sleep
    Downloading autopkg-2.7.2.pkg...
	0..20..40..60..80..100
    Verifying package integrity...
    Getting client resources...
    Allowing idle sleep

    The following items will be installed or upgraded:
        + autopkg-2.7.2
    The following items will be removed:
        - autopkg

Run managedsoftwareupdate --installonly to install the downloaded updates.
Finishing...
    Performing postflight tasks...
Done.

And managedsoftwareupdate --installonly

Managed Software Update Tool
Copyright 2010-2023 The Munki Project
https://github.com/munki/munki

Starting...
    Preventing idle sleep
Removing autopkg (1 of 1)...
    Gathering information on installed packages...
	0..20..40..60..80..100
	0..20..40..60..80..100
    Determining which filesystem items to remove...
    Removing 7268 filesystem items...
	0..20..40..60..80..100
    Removing receipt info...
	0..20..40..60..80..100
    Package removal complete.
Installing autopkg (1 of 1)...
   [ ... ]
    100.0 percent complete...
    The software was successfully installed.
    Allowing idle sleep
Finishing...
    Performing postflight tasks...
Done.

[VitosX]

Additionally, when a package has autoremove set and is added as optional install to any manifest - it is ignored, does not show up in Managed Software Center.app.

[Greg Neagle]

OK, I've reproduced the issue, and you are right, it's not supposed to behave like this.

[Greg Neagle]

I believe I've addressed the issue in the title here: fafca46.

This issue: #1172 (comment) is related, but separate.

I had never considered using autoremove for optional installs; I'm not sure autoremove even makes sense for optional installs, but it should not block the install of an optional install item.

What is your thinking around why you'd use autoremove on an optional install item?

The original thinking behind autoremove was sort of a "safety net" for an admin for items that perhaps were licensed and had limited seats, and this was a way to ensure only machines whose manifest listed the item under managed_installs had the item installed. autoremove would be like a "virtual" managed_uninstall entry for that item.

If you think of it that way, then the fact it does not appear as an optional install makes sense. You've virtually added it to managed_uninstalls, and that takes precedence over optional_installs. (managed_installs and managed_uninstalls take precedence over optional_installs).

For optional_installs, you are saying the user gets to choose whether it is installed or not. It's not clear to me how autoremove should interact with optional_installs.

[VitosX]

Thank you.

As for autoremove on an optional install... I guess it was just accidental discovery during troubleshooting this issue, as I clearly don't have a need for such scenario. I use autoremove for keeping tabs on licensed software (exactly as suggested) and for internal media sets / templates for Final Cut Pro video editing app, which can occupy a lot of disk space and should not be present on a workstation if not explicitly required in managed_installs.

So my main issue was with this unnecessary uninstall-before-update operation, when I uploaded a new version of some package marked with autoremove, which was not present before.

[Greg Neagle]

You can test my fix by copying the updated munkilib/updatecheck/analyze.py to /usr/local/munki/munkilib/updatecheck/analyze.py on a test machine. Assuming it's OK, it will end up in a post 6.3.0 release.

[Greg Neagle]

Addressed in 6.3.1 release.