randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

[Ryan Schmidt]

On Jun 23, 2020, at 00:57, Ken Cunningham wrote:

> On Jun 22, 2020, at 8:32 PM, Ryan Schmidt wrote:
> 
>> I can't corroborate that claim, but of course we are interested in reducing bloat in MacPorts and welcome any suggestions or improvements toward that end.
> 
> I’m surprised — that has always been near point #1 on every homebrew vs. macports discussion, and (was for years) put forth as the major justification for homebrew over macports.

I can't corroborate your claim because I have never attempted to gather authoritative statistics about why people choose MacPorts or Homebrew.

One of the MacPorts advantages you've often touted is how well it works on older systems, something Homebrew doesn't even attempt to do. And I know you're one of the driving forces behind that, and I'm very grateful for that. So you can surely appreciate that one of the ways MacPorts is able to do this is by using its own software instead of that provided by the system. I've often run into the problem that a build will fail on Snow Leopard because its version of Python is too old, so then we have to add a dependency on MacPorts python. To a user of a newer system, that might be perceived as bloat. We could code the port more carefully, only using MacPorts python if it is known that macOS python is too old, and I've done that in some ports, but sometimes we don't know exactly where the cutoff is and so we do what we can at that moment and commit a fix to just make it work. You yourself have suggested multiple times that we should move more towards always using MacPorts compilers on older systems even for ports that don't require it because it's less easier for the maintainer to be able to assume a certain recent baseline functionality, and I've argued against that (on the basis of bloat, on the basis of extra build time on the buildbot as dependencies get activated and deactivated, on the basis of extra wear and tear on the SSDs used on the buildbot).


> 
>> 
>> multiple versions of perl or python3 get pulled in during a build, we should fix that if we can by standardizing on a particular version
> 
> Yes, that indeed is my point. 
> 
> curl, for example, now has a choking amount of dependencies, including 2 perl versions and a python (or two), and yet actually builds on current macOS systems without even a single added dependency just by downloading the source and building it.

My ports are slightly out of date but I don't see a choking amount of dependencies for curl on High Sierra:

$ port rdeps curl
The following ports are dependencies of curl @7.70.0_0+ssl:
  xz
    lbzip2
    libiconv
      gperf
    gettext
      ncurses
  pkgconfig
  libidn2
    autoconf
    automake
    libtool
      xattr
        unzip
    libunistring
      perl5
        perl5.28
          db48
          gdbm
            readline
      texinfo
        help2man
          p5.28-locale-gettext
        perl5.30
  libpsl
    python38
      bzip2
      expat
      libedit
      libffi
      openssl
        zlib
      sqlite3
      python_select
      python3_select
    glib2
      libxml2
        icu
      pcre
  curl-ca-bundle


If you are on an older system you may have additional dependencies in the chain, likely compilers, but that's not curl's fault; it doesn't impose any compiler restrictions. Its dependencies might.

Note that the curl portfile makes no mention at all of python, so if there is an unnecessary python dependency in the chain you'll have to look somewhere other than curl.

Per my rdeps above, the only python used anywhere in the chain is python38, used as a build dependency by libpsl. libpsl used to depend on port:python27 but it was changed to python37 because python2 is eol:

https://trac.macports.org/ticket/58120

It was later updated to python38.

If the build still supports python2, it could be changed to use /usr/bin/python but then it's possible that again for example Snow Leopard's python would be too old. If the build requires python3, not all versions of macOS ship with python3.


The curl-ca-bundle subport does mention a build dependency on perl because the build system uses perl. It used to depend on a specific version of perl because it needed a specific perl module, but that was changed 12 years ago to require merely path:bin/perl:perl5.

https://github.com/macports/macports-ports/commit/6ef755830ba60f7b5977890d6cd46cea7dd0c8db

It is possible that this could be changed to bin:perl:perl5 to allow the macOS version of perl to be used. I haven't tried that but if we want to make that change then I would want to verify that it works as far back as Tiger.


curl and libpsl are both distributable and perl5 and python38 are only build dependencies so they shouldn't get installed on most users' systems just because of their use here, so I would not consider these to be contributors to bloat.


> Feel free to set the bar, if you care to. And hopefully, don’t move it too often…IMHO.

I'm not sure what you mean.