Netatalk 4.x

[Jason Liu]

>
> What if I make a netatalk4 port and give that some time to bake before
> making changes to the netatalk port to select the newer version based on OS?


Off the top of my head, I can't think of any reason why that would be a
problem, but I also don't remember how difficult it would be to turn a
completely separate port into a subport of another later on.

Install count looks super low however.


Yet one more example of why we should be encouraging as many MacPorts users
as possible to be installing the 'mpstats' port, so that we can obtain
better statistics.

-- 
Jason Liu


On Wed, Jan 22, 2025 at 11:35 AM <blake at netjibbing.com> wrote:

> OK thanks for that info. With Netatalk, it shows as building and running
> back to Snow leopard i386 now. What if I make a netatalk4 port and give
> that some time to bake before making changes to the netatalk port to select
> the newer version based on OS? Install count looks super low however. I
> 100% don’t want to break any older setups that already are working.
>
> For now I’ll focus on the meson build issues and getting that all sorted.
>
> On Jan 21, 2025, at 6:11 PM, Jason Liu <jasonliu at umich.edu> wrote:
>
> 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/085c02ba/attachment.htm>