manpages are not compressed on macOS 10.15 and later

[ryandesign (Ryan Carsten Schmidt)]

MacPorts base no longer compresses manpages on macOS 10.15 or later. I request this change be reverted. We previously agreed we would not make such a change because many ports are coded under the assumption that manpages will be compressed. For example, ports might create a symlink to a gzip-compressed manpage, or they might list a gzip-compressed manpage in their select files. (At least the following select groups do so: mysql octave php postgresql python2 python root ruby.) Changing this will break those ports and require them to introduce conditions to do things differently based on the OS version.

[ryandesign (Ryan Carsten Schmidt)]

Also, this creates the problem that noarch ports that install manpages will install different files depending on which macOS version was used to build them.

[ryandesign (Ryan Carsten Schmidt)]

​https://github.com/macports/macports-base/pull/338

[jmroot (Joshua Root)]

Replying to ryandesign:

Also, this creates the problem that noarch ports that install manpages will install different files depending on which macOS version was used to build them.

The files don't differ for ports that set platforms containing "any". For those that don't, it's the same situation regardless of whether they are noarch.

The goal here is for older systems to not hold newer ones back. If creating an inconsistency based on OS version is too inconvenient, the other option would be to not gzip man pages ever.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jmroot:

Replying to ryandesign:

Also, this creates the problem that noarch ports that install manpages will install different files depending on which macOS version was used to build them.

The files don't differ for ports that set platforms containing "any". For those that don't, it's the same situation regardless of whether they are noarch.

Uh yes I meant platforms containing any. I can confirm that any ports built on macOS ≥ 10.15 do indeed still have their manpages compressed. I had not realized from reading the commit that that would be the case as I had no seen any reference to any in the commit. I see now that this is probably handled by the call to _get_compatible_platform.

The goal here is for older systems to not hold newer ones back. If creating an inconsistency based on OS version is too inconvenient, the other option would be to not gzip man pages ever.

The inconsistency is not just based on macOS version; it is also based on OS platform. Some ports can be installed on FreeBSD, Linux, etc. A couple users are trying to use MacPorts on Linux. Homebrew works on Linux. We may at some point want to support Linux or BSD more seriously than we do now. We should not introduce changes like this one that make that more difficult.

I don't consider gzipping manpages to be holding back newer systems. The benefit to newer systems of not gzipping manpages, and relying instead on HFS compression, is negligible. The time taken by MacPorts to gzip manpages and by man to gunzip them is not significant, and the disk space savings of using HFS compression are probably very small. On the other hand, the detriment to older systems by not gzipping manpages is that they will take up significantly more disk space, so please do not consider that option, especially since it does not solve my primary objection to this change, which is that the fact that manpages are gzipped is baked into many ports already. My goal is to avoid having to change all those ports to accommodate this new arbitrary change.

One problem I already mentioned is port select. As an example, install love-0.9 using a binary built by MacPorts 2.9.x and select it and see that the selected manpage works:

% sudo port -b install love-0.9
% port contents love-0.9|grep /man/
  /opt/local/share/man/man6/love-0.9.6.gz
% sudo port select love love-0.9
Selecting 'love-0.9' for 'love' succeeded. 'love-0.9' is now active.
% man love
% sudo port select love none
Selecting 'none' for 'love' succeeded. 'none' is now active.

Now rebuild love-0.9 from source with MacPorts 2.9.99 and do it again:

% sudo port -ns upgrade --force love-0.9
% port contents love-0.9|grep /man/
  /opt/local/share/man/man6/love-0.9.6
% sudo port select love love-0.9
Selecting 'love-0.9' for 'love' failed: could not create new link "/opt/local/share/man/man6/love.6.gz": target "/opt/local/share/man/man6/love-0.9.6.gz" doesn't exist
% sudo port select love none
Selecting 'none' for 'love' succeeded. 'none' is now active.

The select mechanism could at least be fixed in one place centrally by silently removing the .gz extension from manpages referenced in select files. However portfile authors would need to be aware of this "magic" and not reference the non-compressed manpage names in their select files. It is likely that portfile authors would often forget this thus introducing bugs for older systems. Reverting your change avoids these problems.

Prior to your change, MacPorts would uncompress any already compressed manpages and then recompress them at maximum compression. After your change, neither of those steps happens on macOS ≥ 10.15. If your goal was to avoid gzipping manpages and using HFS compression instead on newer systems, you haven't accomplished that. You would need to keep the step that uncompresses already compressed manpages because some ports manually install compressed manpages and many build systems install compressed manpages.

There are numerous ports that do things with compressed manpages:

% port file all|sort -u|xargs grep -E '[[:digit:]]\.gz'

Some of these are simply installing compressed manpages manually but others are operating under the assumption that existing manpages are compressed. For example s-nail installs mailx and mailx.1.gz symlinks:

post-destroot {
    ln -s mail ${destroot}${prefix}/bin/mailx
    ln -s mail.1.gz ${destroot}${prefix}/share/man/man1/mailx.1.gz
}

When built by MacPorts 2.9.99, this would silently install a broken symlink. Finding each such port and adding conditional code to either add or not the .gz extension based on the OS platform and version, and keeping that code around forever (or until MacPorts no longer supports macOS < 10.15 and no longer desires to pretend to support non-macOS systems) is undesirable. It is another situation where portfile authors are likely to write code that works on their current OS, without the .gz extension, which will turn into a bug for users of macOS < 10.15 that will then need to be fixed. Reverting your change avoids these problems.

We have more than enough problems to fix in MacPorts already due to implicit function declarations, implicit int, and incompatible function pointer types errors that we should not manufacture more problems. I will not participate in resolving the problems that this change causes. Please merge the PR I submitted to revert this change.