[MacPorts] #70051: manpages are not compressed on macOS 10.15 and later

[MacPorts]

#70051: manpages are not compressed on macOS 10.15 and later
-------------------------+----------------------
  Reporter:  ryandesign  |      Owner:  (none)
      Type:  defect      |     Status:  new
  Priority:  Normal      |  Milestone:
 Component:  base        |    Version:  2.9.99
Resolution:              |   Keywords:  haspatch
      Port:              |
-------------------------+----------------------

Comment (by ryandesign):

 Replying to [comment:3 jmroot]:
 > Replying to [comment:1 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:

 {{{#!tcl
 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.'''

-- 
Ticket URL: <https://trac.macports.org/ticket/70051#comment:4>
MacPorts <https://www.macports.org/>
Ports system for macOS