mas-cli
App versions with a different version text locally & in MAS cause problems for `update` & `outdated`
mas version
v1.8.8-beta.13
macOS version
15.1.1
macOS build version
24B91
Processor
Apple M3 Max
mas installation method
Homebrew core (brew install mas)
mas installation details
Expected behavior
The latest version of mas may cause an update error with ASUS Device Discovery. Details are as follows:
―― macOS App Store ――
Upgrading 1 outdated application:
ASUS Device Discovery (1.1.18) -> (1.0.0.1.18)
==> Downloaded ASUS Device Discovery (1.1.18)
==> Installing ASUS Device Discovery (1.1.18)
==> Installed ASUS Device Discovery (1.1.18)
―― macOS system update ――
No updates are available.
Software Update Tool
Actual behavior
Steps to reproduce
topgrade
Additional context
No response
@Accademia mas compares the version from the app itself against the version for the app from the Mac App Store.
ASUS used 1.1.18 as the version in the app itself, while they used 1.0.0.1.18 as the version in the Mac App Store.
The ways around this would be to:
- somehow find the equivalent of the local app version in Mac App Store data, or the Mac App Store version in the local data (I haven't found either after a quick investigation)
- compare some other version identifier between the local app info & the Mac App Store info (like the
kMDItemAppStoreInstallerVersionIDproperty from Spotlight, which doesn't seem to be available from the Mac App Store endpoint that we use) - somehow ask if there are updates for any of the installed apps, rather than mas itself comparing the local app version with the Mac App Store app version
- always ask for an update for each relevant app, but ensure that no updates are unnecessarily downloaded or are installed
@Accademia mas compares the version from the app itself against the version for the app from the Mac App Store.
ASUS used 1.1.18 as the version in the app itself, while they used 1.0.0.1.18 as the version in the Mac App Store.
The ways around this would be to:
- somehow find the equivalent of the local app version in Mac App Store data, or the Mac App Store version in the local data (I haven't found either after a quick investigation)
- compare some other version identifier between the local app info & the Mac App Store info (like the
kMDItemAppStoreInstallerVersionIDproperty from Spotlight, which doesn't seem to be available from the Mac App Store endpoint that we use)- somehow ask if there are updates for any of the installed apps, rather than mas itself comparing the local app version with the Mac App Store app version
- always ask for an update for each relevant app, but ensure that no updates are unnecessarily downloaded or are installed
Thank you very much for your response! Thank you for resolving my confusion.
@Accademia Thanks for the issue report.
It will probably take some time to get to this, as there are other pressing issues in the task queue, and because solving this will probably require extracting headers for private frameworks from the DSC for multiple macOS versions, which will take time to get working (it's a long story).
@Accademia See note at the beginning of #386 to see how version ignoring might mitigate this issue.
mas upgrade could check each "upgraded" app after the "upgrade" finished; if the same version to which the app was "upgraded" is still offered as an upgrade, then it could output a suggestion to the user to use a command-line like the following to ignore the seemingly spurious update in the future. e.g., for your app:
mas pin --exclude '1\.0\.0\.1\.18' 995124504
Unfortunately, the pin would need be changed after real every upgrade to a new version if they continually insert .0.0 in their Mac App Store versions. We could try to allow a syntax where the exclusion could generically reference the current version, i.e. it would ignore anything matching <current-major-version>\.0\.0<current-version-after-major>, so the pin wouldn't need to be updated after every real upgrade, but that will probably be way too much work for way too little gain.
Just looking at the output above and also in this issue, it seems that mas is (or could be) aware of the version mismatch at download time.
In the Cinebench example, there is this output:
Upgrading 1 outdated application:
Cinebench (23.2) -> (23.200)
==> Downloading Cinebench (23.2)
==> Downloaded Cinebench (23.2)
So when it gets to the "Downloading" step it should be able to notice that the build that it is trying to download (23.2) doesn't match the version on offer in the App Store (23.200), but it does match the version that is already installed.
Where does the version number in Downloading Cinebench (23.2) come from?
@AaronKelley It comes from SSDownloadMetadata, IIRC.
I mentioned something similar to your idea in a comment on some other issue, IIRC. There were some issues with my initial idea of how to implement it, but I think the simplest solution might be:
-
outdated: initiate updates for all apps; immediately cancel each update (without displaying any progress info for any of the "updates"); display an app as outdated if its download's version number is not the same as its installed version number. -
update: initiate updates for all apps specified by the command line; immediately cancel any update whose version number matches the installed version number, unless--forcehas been used.