autoconf: allow Release to contain hyphen

[lundman]

To avoid clashing with tags and releases, we'll use "zfs-macOS".

Motivation and Context

Description

Meta:          1
Name:          zfs-macOS

#define ZFS_META_GITREV "zfs-macOS-2.1.99-85-g872655ba48-dirty"

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[behlendorf]

I'm a little concerned this might cause some subtle problems since the packaging convention is that hyphens are used to separate the name, version, and release. Allowing a hyphen as part of the name makes it unclear for anything parsing this string where the version and release fields start.

Would it perhaps make more sense to include the "macOS" component in the release field? Is the motivation here to keep the package naming consistent while moving to the upstream code?

[tonyhutter]

> #define ZFS_META_GITREV "zfs-macOS-2.1.99-85-g872655ba48-dirty"

Maybe I'm doing something wrong but I'm not getting that line in my zfs_gitrev.h. Here's what I did:

$ cat META 
Meta:          1
Name:          zfs-macOS
Branch:        1.0
Version:       2.1.99
Release:       1
Release-Tags:  relext
License:       CDDL
Author:        OpenZFS
Linux-Maximum: 5.13
Linux-Minimum: 3.10

$ rm ./include/zfs_gitrev.h
$ ./autogen.sh && ./configure && make -j9
$ cat ./include/zfs_gitrev.h
#define	ZFS_META_GITREV "zfs-2.1.99-397-gbf2032725-dirty"

If I do a make dist I do correctly see the tarball get named zfs-macos-2.1.99.tar.gz though.

[lundman]

#define ZFS_META_GITREV "zfs-macOS-2.1.99-85-g872655ba48-dirty"

Apologies - I put that in as an example as to what the version string would look like. To get gitrev to be correct, we simply have to git tag it that way. That is fine, and no change needed.

What it comes down to is three things;

#define ZFS_META_GITREV "zfs-macOS-2.1.99-85-g872655ba48-dirty"

Comes from git tag, no issues.

# sysctl zfs.kext_version
zfs.kext_version: 2.1.99-97_g396215b709

Kernel version string, produced by ZFS_META_VERSION - ZFS_META_RELEASE.
But this is in macOS source files, so we control that - no problem.

Finally;

# zpool version
zfs-macOS-2.1.99-97_g396215b709
zfs-kmod-2.1.99-97_g396215b709

The kernel version comes from macOS sources, and we read it from sysctl. Then it prepends it with "zfs-kmod" - ugly as hell, but small price to be consistent with other platforms. It should probably say kext though.
Userland however, is from ZFS_META_ALIAS which is produced from ZFS_META_ALIAS="$ZFS_META_NAME-$ZFS_META_VERSION"
where $ZFS_META_NAME is from META file and says zfs normally.

If we change $ZFS_META_NAME to say zfs-macOS it fails and just leaves zfs in there.

So we either stop using hyphen in the META file, or autoconf is fixed to be able to handle a hyphen. Since Linux will not use hyphens in META, they should not be affected by this commit (we hope).
Sure we could put zfsMacOS in META but eww.

We need our git tags to be unique to that of Linux (at least for now) since otherwise we'd overlap. Which means the version displayed to the users also need to be reflecting that.

We could also move userland version from common files into _os files, or, #ifdef, or make it based on git tag, instead of META file.

When addressing this issue, we just took the path that seemed to "fix the thing that was broken", but honestly, I don't really mind how it is addressed, it's just cosmetics! :)

[behlendorf]

I see, thanks for the explanation. Then I think this should be fine.