Version in name of *.dmg file does not match 'version' in 'PackageInfo' file

[John Lockwood]

Installers for macOS as hosted at ​https://sourceforge.net/projects/smartmontools/files/smartmontools/ appear to use an unusual format of version number e.g. 7.3-1, 7.4-1, etc.

It is far more common for a version number to be something like 7.3, 7.3.1, 7.4, 7.4.1 and even 7.4b12

Whilst the installer pkg 'works' this unusual version format upsets at least some enterprise tools for the automated distribution and installation of these installers because they seem to ignore the -1 portion of the version number and therefore would treat 7.4 and 7.4-1 as being the same version.

In this case particularly a tool called AutoPkg which is widely used in the Mac world.

This has therefore resulted in the just released 7.4-1 being treated as the same version as the previous 7.4

[John Lockwood]

Ok, further investigation suggests it is a different issue _but still an error_.

It appears that both the 7.4 and the new 7.4-1 installer pkg's are actually labelled in the installer pkg as being version 7.4

Hence AutoPkg and Munki are tricked in to thinking the version of the installer is 7.4 when it should be different.

So, it does not appear to be the format of the version number but rather whilst the file name has a different 'version' the actually installer pkg does not.

This still counts as an error and one that sadly is far more commonly made by developers. I used to have to deal with a backup client installer and literally every single release had a version identifier of 1.0 for the installer pkg!

[Alex Samorukov]

Hi, and thank you for the report. I'm not sure if I really understand the issue, as there was no version of the macOS installer without prefixes, so I'm not sure which version you compared to. Please provide more details.

[Alex Samorukov]

I think the point here was to be able to update the installer without re-releasing the new version. I am not sure if it is really something we have to do, so it is likely we can drop the -x suffix from the next releases. But I still don't understand how it could impact the tools you mentioned.

[John Lockwood]

The issue is that the installer with 7.4 in the file name and the (newer) installer with 7.4-1 in the file name which are supposed to be different versions actually have encoded in the installer pkg files the same version number i.e. 7.4.

As a result as I mentioned, enterprise tools for deploying these installers on Macs identify both as the same version and hence get confused as they cannot tell which is newer.

I have seen sadly many, many times developers i.e. whoever creates the installer pkg make similar mistakes and either label all pkgs as e.g. 1.0 and not even try to do things properly, or in this case perhaps a simpler matter of forgetting to update the version string embedded in the pkg file at the same time as building a new one with a new file name.

So common is this type of mistake that the enterprise tool I am using which is called Munki actually has specific additional capabilities to look at (usually) the item being installed for its version details and use that to override the version information of the installer pkg itself. Unfortunately this relies on the contents being a Mac application or 'bundle' which both would have standard Info.plist files in them from which version information is available. As Smartmontools does not contain such types of files this approach is not possible in this case and hence one can only use the PackageInfo file in the installer pkg which as mentioned has not been updated to reflect that it is a newer version than the previous 7.4 release.

There maybe other ways, but it is possible to use the Mac built-in pkgutil command to 'expand' the pkg installer file to a directory and examine the contents without installing it. As mentioned this then allows access to the PackageInfo file and that file is an XML file containing the following.

<pkg-info format-version="2" identifier="com.smartmontools.pkg" version="7.4" install-location="/" auth="root">
<payload installKBytes="5048" numberOfFiles="44"/>
<!-- <scripts>
    <postinstall file="./postinstall"/>
</scripts> -->
</pkg-info>

As you can see on the first line, it says it is version 7.4 and this was from the 7.4-1 file. As a result it cannot be by automated tools differentiated from the previous release.

[Alex Samorukov]

but where do you got 7.4.dmg ? i think it was never ever released

[John Lockwood]

At best, this will result in enterprise deployment tools failing to install a new updated version - leaving machines with the older version installed. At worst this might result in a loop with it installing the newer version, not seeing a different version number and then re-installing the newer version repeatedly. Both possibilities are undesirable.

[Alex Samorukov]

sorry, i really cant get why you still talking about 2 dmg versions. We never had 7.4-0 or 7.4.dmg according to my knowledge. I am kind of agree that we should probably not have this suffix at all, but I don't really understand how it may cause any problems for any tools if we don't have -0 and never had.

[John Lockwood]

Replying to Alex Samorukov:

but where do you got 7.4.dmg ? i think it was never ever released

Hmm. Interesting point. Something else also seems to have happened. I am using a combination of two Mac enterprise tools. The first is AutoPkg which handles automatically finding and downloading updates for software. The second is Munki which handles distributing these updates and installing them automatically to a fleet of Mac computers.

This week AutoPkg decided there had been a new version, my AutoPkg and Munki setup had already previously downloaded the 'latest' version and labelled it as 7.4.

I had seen a 7.4 file here - ​https://sourceforge.net/projects/smartmontools/files/smartmontools/7.4/

However going back now I see that there is no DMG file and only the source for that version. With my setup having already downloaded previously what it thought was version 7.4 due to the PackageInfo calling the 7.4-1 file that, I had taken these two facts and thought there was a 7.4.dmg.

So either - and I am not saying this is true, a 7.4.dmg had existed and has been deleted and this week a 7.4-1 added and frankly I don't think this is the case, I can see the file shows a March date. Or something else tricked AutoPkg in to thinking the file on SourceForge had changed.

So, I would now agree that there has not been two releases with the same version string and I apologise for my mistake. However, I would still consider it to be better practise to ensure the file name version and the actual embedded version information should be the same to avoid such confusion. That is in this case both should have been 7.4-1.

It is NOT worth building a new version this time just to correct that, but hopefully you will take this on-board for the future.

Note: I also build installer packages myself, both to repackage items for enterprise distribution and for my own opensource projects.

[Alex Samorukov]

Christian, is it a good idea to remove -1 suffix for the next release? I think that for security reasons, it should be better never to have 2 packages of the same version with different suffixes. If we make a mistake and want to update anything - we can always use 7.1.2, etc

[Christian Franke]

Replying to John Lockwood:

I had seen a 7.4 file here - ​https://sourceforge.net/projects/smartmontools/files/smartmontools/7.4/

We never released any smartmontools-X.Y.dmg. We provide smartmontools-X.Y-1.dmg since 6.5 from May 2016. I don't remember any similar problem report since then.

Replying to Alex Samorukov:

Christian, is it a good idea to remove -1 suffix for the next release? ...

It is common practice to use X.Y-1 for a package built from source package X.Y. Therefore an alternative may be to enhance the build recipes such that the PackageInfo file contains version=$VERSION-$REVISION if REVISION is configured (e.g. --with-revision=1).
If this would not help, we could also drop the -1 from the DMG package for next release.

... I think that for security reasons, it should be better never to have 2 packages of the same version with different suffixes. If we make a mistake and want to update anything - we can always use 7.1.2, etc

Using .2 instead of -2 would require to built a branched source package even if no source code changes (instead of version number) are present. The new source tarball would trigger unnecessary updates on other platforms. A missing source tarball would trigger complaints.

[Alex Samorukov]

Replying to Christian Franke:
, etc

Using .2 instead of -2 would require to built a branched source package even if no source code changes (instead of version number) are present. The new source tarball would trigger unnecessary updates on other platforms. A missing source tarball would trigger complaints.

This is my point. If we are building from CI (which is the case), we should not have a situation where it is possible to build -2 without changing the source. And I think, given recent security incidents with libxz + a lot of work done to make CI builds repeatable, we should avoid any non-CI releases. Unnecessary updates on other platforms to me does not seem like a big overkill and very often happen with other OSS projects (e.g., version 1.2.x releases with changes for only one of the supported platforms)

[Christian Franke]

I agree and created the new ticket #1825.

Summary of this ticket adjusted to be more specific. This will be fixed as a positive side effect of #1825.