Publicizing MacPorts

[Mojca Miklavec]

On Sat, 24 Apr 2021 at 13:04, Georges Martin <jrjsmrtn at gmail.com> wrote:
>
> Le 22 avr. 2021 à 17:46, Steven Smith <steve.t.smith at gmail.com> a écrit :
>
> Another reason major news like M1 support must be announced.
>
>
> May I ask: how do we *define* "M1 support" in MacPorts? What are the *metrics* used to support that statement?
>
> - How does the MacPorts base "support the M1"? (I know I had to install it from git then switch to the master branch for other reasons -- not a typical user installation)
>
> - Is it when you set buildfromsource to always, build_arch to arm64 and everything run smoothly afterwards? :-)

You go to https://www.macports.org/install.php, download the pkg and run it.

It's usually before the official release of the new OS that one needs
to install MacPorts base from source, but that's mainly because one
needs to sign some kind of agreement with Apple that prevents
developers from doing certain things and reveal details about the beta
to public. Or at least it's my understanding that we may not
distribute binaries for beta versions before the official release.

Building base from source is useful for anyone who wants to help with
testing or development though.

> - How does a port "supports the M1"? Is it when it can be built, tested and installed on a M1? Even if it's just compiled as x86_64 and running on Rosetta? Or is it when it can be successfully built, tested and installed as native and/or +universal  on both M1 and Intel?

Yes, when it builds without any hassle & intervention on M1, and the
resulting software works. Bonus points if it comes as a binary. If
certain software cannot be built natively, but still works as x86_64,
I would also call this supported. But keep in mind that it's actually
a lot more work to ensure that a particular port can be built for
another architecture, than it is to make it build natively. Plenty of
ports just worked, while some other software may never get ported
properly.

> - How many ports are building on M1 today? (can a user do a search on architecture on ports.macports.org?) Before installing, how can a user know if a port is building/testing successfully on M1? (can he do a `port info --name --supported-archs` on a port?)

You can go to
    https://ports.macports.org/ports/all_builds/
and select 11_arm64 as the builder (it's a pity that we don't have a
direct link, but that could be added).

The arm64 builder was missing for a short while (it's 270 commits
behind at the moment of writing), but it's slowly catching up:
    https://build.macports.org/waterfall?tag=11
and some ports that haven't seen any updates in a long while might not
have been attempted to build (that might happen in a few days).

> - What if a port is not building on M1 because upstream is not ready yet? (libffi, openjdk16, ghc comes to mind) What if ports are not building because major dependencies are not? (thinking of you, libffi) Is it documented anywhere?

If either upstream is not ready, or if one of the dependencies (even
if that dependency means a broken compiler) is broken, then the port
is broken. The best reference we have at the moment is probably
    https://ports.macports.org/port/ghc/

You can combine the information from:
- port health that tells you whether the port built successfully on
the buildbot worker in question
- installation statistics submitted by users (where you can see that
nobody has ghc installed on arm64, for example)
- the list of Trac tickets

> - How are M1 porting priorities defined? Do we have "M1 priorities" or "M1 call for help" for maintainers? Is there a M1 "Hot Problems" page for users and maintainers like we have for macOS releases?

We don't have any "M1 priorities" list at the moment.
We have some kind of approximation of the most popular ports here:
    https://ports.macports.org/statistics/ports/?days=30&first=-total_count&second=-req_count&third=port
and I believe that we added some information about whether the port is
broken or not to the new ports page that hasn't been deployed yet (I'm
not 100% sure).

> To be clear: I am **not** complaining. I switched to M1 a month and a half ago and decided to contribute to the effort as much as I can: I installed from git, set up buildfromsource to always and build_arch to arm64, then switched to git master. After Ken's call for help on ICU, I set my variants to +universal, recompiled everything that could be (but had to stop because of libffi...).  I'm trying to natively build all the ports I was using on Catalina/x86_64, I'm not there yet (today, py{38,39}-pandas do not build anymore because of OpenBLAS...) and I am not complaining: it's part of the game... :-)

One of the problems with "call for help" at the moment is that we have
waaaaaaaaay too many tickets open, and it's basically impossible to
figure out which ones are most important to look into.

For anyone possessing a M1 mac probably the best way to contribute by
far is to help build those ports which that particular user needs.

Many ports just work. A non-negligible number software packages
probably require an effort in porting that greatly exceeds the
bandwidth of port maintainers.

> But: I'm afraid this "marketing" effort could backfire if we don't clearly define what "M1 support" means and provide some metrics to maintainers and users. As well as news sites.

What kind of metrics would you provide to users?
Probably a slightly improved search of ports that allows you to either
search or sort based on different criteria, and then filter just arm
builds would be best. This has already been greatly improved, see
    https://arjunsalyan.com/gsoc20-report/
it has just not been deployed yet. (This doesn't mean that we
shouldn't promote MacPorts.)

Mojca