Netatalk 4.x

[Jason Liu]

Take a look at the Portfile for MoltenVK:

https://github.com/macports/macports-ports/blob/master/graphics/MoltenVK/Portfile

The base MoltenVK port, which is just a stub, will select the correct
versioned subport based on the user's macOS version. Unfortunately, there
is no way to know how to divide up the if-else statements unless you know
which macOS versions can handle which version of netatalk. The only way to
find out this information is to either gather it from the historical
changelogs of the upstream package, or to actually test using old macOS
versions (this is really the only truly accurate method). The second method
is often considered to be a compelling reason why those of us MacPorts devs
who are interested in supporting older macOS versions will sometimes set up
virtual machines for each and every older macOS version.

-- 
Jason Liu


On Wed, Jan 22, 2025 at 9:12 AM Blake Garner <blake at netjibbing.com> wrote:

> I like that idea. Is there a good example port that already does this? My
> plan is to get a functional PR started and hope for some collaborative
> advice.
>
> I’m not very interested in spending a lot of effort testing every possible
> version of macOS. Can these supports have their own supported macOS
> versions?
>
> Can older OS versions select the netatalk2 support?
>
>
>
> On Jan 20, 2025, at 6:37 PM, Sergey Fedorov <vital.had at gmail.com> wrote:
>
> 
> Yeah, this is a better idea, perhaps.
>
> On Tue, Jan 21, 2025 at 10:13 AM Jason Liu <jasonliu at umich.edu> wrote:
>
>> Whoever updates the Portfile, can you make sure to preserve the old
>> version(s) of netatalk using a versioned subport, i.e. 'netatalk3',
>> 'netatalk2' (or whatever), so that old versions of macOS can still use the
>> older netatalk packages? I think that the 'netatalk' port should be
>> whatever is the latest version of the package, instead of having a new port
>> called 'netatalk4'.
>>
>> --
>> Jason Liu
>>
>>
>> On Tue, Jan 21, 2025 at 4:28 AM Sergey Fedorov <vital.had at gmail.com>
>> wrote:
>>
>>> I had a port for netatalk 3 somewhere; as I recall, it needed some fixes
>>> for the build. That was a while ago, I do not know what is the current
>>> status.
>>> Very much likely that netatalk 4 will be broken on older systems and
>>> possibly less useful than earlier versions.
>>> So yeah, I think it should be a separate port rather than an upgrade of
>>> existing one.
>>>
>>> On Tue, Jan 21, 2025 at 3:23 AM <blake at netjibbing.com> wrote:
>>>
>>>> The Netatalk package has seen some serious updates recently with a new
>>>> team working on it. I have made a couple efforts and getting a working port
>>>> for the 4.x versions but meson build system is tripping me up. Also looking
>>>> at compatbility it seems like we would want a netatalk4 package vs just
>>>> updating the netatalk package. That said there is a support statment to
>>>> consider.
>>>>
>>>> "18th of January 2025
>>>> The Netatalk Project has published its End of Life policy. We guarantee
>>>> that each release series will be supported with security patches for 12
>>>> months after the release of the superseding feature release.
>>>> Most urgently, this means that the long-running 3.1 release series will
>>>> be out of support after May 31st, 2025. Users and downstream packagers are
>>>> encouraged to upgrade to the latest Netatalk 4.1 release series."
>>>>
>>>>
>>>> My “works on my machine” WIP for the port
>>>> https://github.com/trodemaster/macports-ports/blob/add-netatalk4/net/netatalk4/Portfile
>>>>
>>>> The meson build system only has one flag for the path to bdb for
>>>> example. With include and lib needing to be specified for MacPorts
>>>> compatibility, it seems like I would need to hack up the meson config to
>>>> get the current version to build. For no I’m pointin to some local
>>>> filesystem as a hack to make it build.
>>>>  /Users/blake/scratch/netatalk/bdb/
>>>> ├──  db48 -> /opt/local/lib/db48/
>>>> ├──  include -> /opt/local/include/db48/
>>>> └── lib -> /opt/local/lib/db48/
>>>>
>>>> There are also a bunch of other binaries that are part of hte package
>>>> and having those built as variants seems like a good plan. See features
>>>> setion https://netatalk.io
>>>>
>>>> Suggestions for ports using meson that are good reference?
>>>>
>>>> Homebrew reference
>>>> https://github.com/Homebrew/homebrew-core/blob/67dd3977058cd517d3d5394afd400ad00e708f38/Formula/n/netatalk.rb
>>>>
>>>> Thanks,
>>>> Blake
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20250122/2f8bf0ba/attachment.htm>