netatalk: update to 4.3.2 #29293

trodemaster · 2025-09-09T04:14:04Z

Netatalk Port Consolidation and Update

This PR consolidates the netatalk and netatalk4 ports into a single port with subports and updates to version 4.3.2 from the new upstream maintainer.

Description

Netatalk is a freely-available Open Source AFP fileserver that allows Unix-like operating systems to serve as file servers for Macintosh computers. This update consolidates the separate netatalk and netatalk4 ports into a single port with subports, providing a cleaner port structure while maintaining backward compatibility.

Key Changes

combine netatalk and netatalk4 into single port with subports
update to version 4.3.2 from new upstream maintainer
switch to GitHub source and Meson build system
modernize dependencies and configuration
remove unused netatalk4 port files

Testing Performed

Port builds successfully locally
Port lint passes with 0 errors and 0 warnings
Dependencies verified
Installation tested

Tested on

macOS 15.6.1 Xcode 16.4 / Command Line Tools 16.4.0.0.1.1747106510 (arm64)

Port Details

Category: net
Version: 4.3.2
Homepage: https://netatalk.io
License: GPL-2+
Dependencies: sqlite3, libevent, libgcrypt, iniparser, tracker3, dbus, talloc, glib2, bstring

Maintainer

@trodemaster (openmaintainer)

Ticket References

This PR addresses multiple long-standing tickets:

Closes: https://trac.macports.org/ticket/69609 (netatalk 2.3.1 new upstream maintainer and updated source)
Closes: https://trac.macports.org/ticket/36674 (netatalk: error: incomplete definition of type 'struct _ipp_s')
Closes: https://trac.macports.org/ticket/36673 (netatalk: update to 3.0.1)
Please also close: https://trac.macports.org/ticket/23313 as the solution is in the new docs

barracuda156 · 2025-09-09T08:47:40Z

This does not work correctly (of course): there are no version for netatalk and no checksums for netatalk4, this just confuses subports into a single netatalk.

If the idea is to make sure users install v. 4 by default and not v. 2, what should be done instead is:

a) make a new subport netatalk2,
b) update netatalk to 4.3.2,
c) mark netatalk4 as obsolete and replaced by netatalk,
d) make sure dependents build with netatalk (v. 4), if there are any, and revbump them (if some do not, make them depend on netatalk2, also revbump).

If not, then perhaps there is no need to combine ports at all, just update netatalk4.

barracuda156

In any case v. 4 requires C11 and legacysupport. After that, this builds fine, though I see no reason to kill v. 2, there were reasons to keep it instead of just updating directly.

net/netatalk/Portfile

trodemaster · 2025-09-10T20:33:14Z

Netatalk 4 has matured to the point that it now replaces Netatalk 2.x. Netatalk4 is building all the way back to El Capitan as is. https://ports.macports.org/port/netatalk4/details/ There is no reason to keep or make a new Netatalk2 port; the existing one has been abandoned for years.

If I mark netatalk4 as obsolete to simplify things into a single port, I can do that. The subport approach I have configured here works just fine in my testing and the actions builds.

barracuda156 · 2025-09-10T21:41:55Z

You do not have to maintain a port if you have no interest, but it is wrong to break it for multiple supported systems, and as you point out, netatalk4 here is broken on Yosemite and below.
The easiest way is to keep netatalk2 for them. If you wish, you can make it in a single profile as a fallback version. If have a nomaintainer port for netatalk2.
Whether something is ”abandoned” is largely irrelevant, as long as it works. There are a lot of ports not receiving updates for years, it is not a reason to trash them.

trodemaster · 2025-09-11T02:07:27Z

Netatalk 4 has all the features and capabiliteis of netatalk 2 now. That's why it's time to have a single port that provides these capabilites. From what I can tell there is near zero usage of netatalk 2. We have both worked with the upstream maintainer to resolve backwards compatabiliity issues for netatalk already. That work can continue.

barracuda156 · 2025-09-11T02:35:24Z

If at least you fix compiler choice (set C11 standard) and add legacysupport, as I point above, that will unbreak the port for some systems that currently fail.

I don’t get why this should be a point of argument when the source explicitly requires C11:
https://github.com/Netatalk/netatalk/blob/main/meson.build#L6
And I also specified why legacysupport is needed; if you want, I can grep sources and find exact places where functions in question are used.

barracuda156 · 2025-09-11T06:25:54Z

@trodemaster Ok, so these require legacysupport for < 10.11:

openat (< 10.10): https://github.com/Netatalk/netatalk/blob/4adc574989973097c03460f38e8f3ec8766274d2/bin/ad/ftw.c#L419
_SC_PHYS_PAGES (< 10.11): https://github.com/Netatalk/netatalk/blob/4adc574989973097c03460f38e8f3ec8766274d2/bin/ad/ad_cp.c#L840

And this is why the port is broken, _SC_PHYS_PAGES is not available before macOS 10.11, see: https://github.com/macports/macports-legacy-support/blob/17cb4f9a1e313356db8acd1b3f8ae317ddacaf11/README.md

rdmark · 2025-09-11T21:27:35Z

@trodemaster Ok, so these require legacysupport for < 10.11:
1. `openat` (< 10.10): https://github.com/Netatalk/netatalk/blob/4adc574989973097c03460f38e8f3ec8766274d2/bin/ad/ftw.c#L419

2. `_SC_PHYS_PAGES` (< 10.11): https://github.com/Netatalk/netatalk/blob/4adc574989973097c03460f38e8f3ec8766274d2/bin/ad/ad_cp.c#L840
And this is why the port is broken, _SC_PHYS_PAGES is not available before macOS 10.11, see: https://github.com/macports/macports-legacy-support/blob/17cb4f9a1e313356db8acd1b3f8ae317ddacaf11/README.md

Are these two symbols the only ones in the netatalk code that are incompatible with older macOS, or are there more of them?

I think I could fairly easily refactor away _SC_PHYS_PAGES.

trodemaster · 2025-09-11T22:53:32Z

I'll add legacycupport and see how that effects the build on my local test setup.

@barracuda156 for "fix compiler choice (set C11 standard)" I would appreciate an example on how to do this correctly.

trodemaster · 2025-09-12T00:54:33Z

legacysupport 1.1 and c standard 2011 added

barracuda156 · 2025-09-12T01:14:52Z

@rdmark I am not sure how to easily check that.

net/netatalk/Portfile

trodemaster · 2025-09-19T17:06:57Z

OK, I have refactored my approach to maintain Netatalk 2.x for systems older than 10.11, which is the current cutoff for Netatalk. If upstream changes allow building on older versions in future releases, we can adjust the cutoff appropriately.

Take a look @barracuda156

I would greatly appreciate a review of this approach from a committer as well. It's my first attempt at creating a complex port like this.

barracuda156 · 2025-09-22T12:13:34Z

@trodemaster Sorry for a delay, the weekend was pretty busy. I will run the build from your updated PR today.

barracuda156 · 2025-09-23T00:23:35Z

net/netatalk/Portfile

+    use_xz              yes
+    revision            0
+
+    platforms           {darwin >= 11}


There is no benefit in prohibiting to build a port which builds fine. Defaults can be set as you decide to (so that netatalk pulls in either v.4 or v.2), but rather allow a user to install either of the ports explicitly, if desired.

Besides, my objection was about deleting v.2 (without knowing for sure that v.4 is a proper replacement for every system), not about making v.4 the default. Maybe just make netatalk a stub for netatalk4 for all systems, but retain v.2 for the time-being (i.e. the subport which you have added here)? Otherwise it is a bit confusing: it will install with 4.3.2 version, even when it actually installs v.2.

We know 100% for sure that netatalk 4 is a replacemnt for netatalk 2.x. The 2.x has been depricated and replaced with 4.x. Have you looked at netatalk.io as it has the details.

If the upstream actually tested it on 10.5+, then sure, 2.x can be just retired. (My default assumption is that nothing is tested on older systems.)

Your welcome to make bug reports on the upstream for those systems. Upstream has been fixing these kinds of things when reported.

I don’t really get what is the argument about at this point. You wanted to make netatalk4 the default for all systems? I am fine with that (since the build should be fixed now). Since you asked me to review the changes, I commented on those. You could use my suggestions while making your choice on defaults (whether using v4 for all systems or for a subset of them). There are no objections to moving to v4 as the default. I can’t approve arbitrary platforms blacklisting, because it forces a user to edit portfiles manually to build a port, so there is a real downside with zero benefits. However, my approval is not something required to merge the PR anyway.

barracuda156 · 2025-09-23T00:25:19Z

net/netatalk/Portfile

+    startupitem.restart "${prefix}/etc/netatalk/initscript restart"
+
+    depends_build-append \
+                        port:pkgconfig


Could it be made path-style, like above?

barracuda156 · 2025-09-23T00:27:53Z

net/netatalk/Portfile

+
+    version             2.2.10
+    revision            0
+    platforms           {darwin < 11}


Likewise, IMO it is not justified to prohibit building the port on systems where it builds. It can be discouraged (in favor of v.4), but that is already done via netatalk stub. If needed, a port note can be added, advising to switch to v.4. But if someone needs to test something with v.2 on a newer macOS, why would we prevent that?

The goal here is to replace the out of date software with the current release.

I get that, but arbitrary restriction of platforms does not serve that purpose. If the stub pulls in v.4, the goal is already achieved: port install netatalk will install netatalk4.

trodemaster · 2025-09-24T03:47:36Z

Look @barracuda156, I'm holding off making any changes regarding maintaining old versions of netatalk until a committer has time to assist with this and provide feedback. People are busy with Tahoe changes and I can wait for that dust to settle.

macportsbot added type: update maintainer maintainer: open Affects an openmaintainer port labels Sep 9, 2025

barracuda156 suggested changes Sep 9, 2025

View reviewed changes

net/netatalk/Portfile Outdated Show resolved Hide resolved

net/netatalk/Portfile Show resolved Hide resolved

trodemaster force-pushed the net/netatalk-consolidate-ports branch from 510dea7 to b117bf6 Compare September 11, 2025 23:37

barracuda156 reviewed Sep 12, 2025

View reviewed changes

net/netatalk/Portfile Outdated Show resolved Hide resolved

trodemaster force-pushed the net/netatalk-consolidate-ports branch from b117bf6 to 95855b9 Compare September 12, 2025 02:13

trodemaster force-pushed the net/netatalk-consolidate-ports branch 2 times, most recently from 821c9a6 to 27c2017 Compare September 19, 2025 16:46

trodemaster force-pushed the net/netatalk-consolidate-ports branch from 3a3cd30 to 7b6b4d5 Compare September 19, 2025 17:26

netatalk: update to 4.3.2

b35950e

trodemaster force-pushed the net/netatalk-consolidate-ports branch from 7b6b4d5 to b35950e Compare September 19, 2025 21:01

barracuda156 suggested changes Sep 23, 2025

View reviewed changes

Uh oh!

netatalk: update to 4.3.2 #29293

Are you sure you want to change the base?

netatalk: update to 4.3.2 #29293

Conversation

trodemaster commented Sep 9, 2025

Netatalk Port Consolidation and Update

Description

Key Changes

Testing Performed

Port Details

Maintainer

Ticket References

Uh oh!

barracuda156 commented Sep 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

barracuda156 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

trodemaster commented Sep 10, 2025

Uh oh!

barracuda156 commented Sep 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

trodemaster commented Sep 11, 2025

Uh oh!

barracuda156 commented Sep 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

barracuda156 commented Sep 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rdmark commented Sep 11, 2025

Uh oh!

trodemaster commented Sep 11, 2025

Uh oh!

trodemaster commented Sep 12, 2025

Uh oh!

barracuda156 commented Sep 12, 2025

Uh oh!

Uh oh!

trodemaster commented Sep 19, 2025

Uh oh!

barracuda156 commented Sep 22, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

trodemaster commented Sep 24, 2025

Uh oh!

Uh oh!

barracuda156 commented Sep 9, 2025 •

edited

Loading

barracuda156 commented Sep 10, 2025 •

edited

Loading

barracuda156 commented Sep 11, 2025 •

edited

Loading

barracuda156 commented Sep 11, 2025 •

edited

Loading