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.
