Netatalk 3.2.x conflict with Samba 4.19 on FreeBSD due to talloc

[andylemin]

Describe the bug
Cannot run both Netatalk 3.2.x and Samba 4.19 on FreeBSD 14.1, as Netatalk requires talloc is present, and Samba requires it is absent.

To Reproduce
pkg install samba419 automatically removes talloc (breaking Netatalk).

pkg install talloc automatically removes samba..

Expected behavior
Samba and Netatalk can coexist on the same server.

Environment

• Server OS: FreeBSD 14.1
• Netatalk Version 3.2.4

[andylemin]

Conflict message that is causing one or the other to be removed;
'talloc-2.3.4_1 conflicts with samba419-4.19.7 on /usr/local/lib/python3.11/site-packages/talloc.cpython-311.so'

I understand Netatalk recently went through a cleanup effort regarding talloc, seems this might have been the reason why it was the way it was.
Might be tricky to find an ideal balance/compromise.

Mixed client environments (windows and mac) are still common for many businesses.

[rdmark]

This is quite unfortunate, and IMHO the proper solution would to be to convince the FreeBSD port maintainer to repackage the samba port to use the system talloc library instead of the bundled code. This is what Debian is doing, for instance, since they have a strict policy against "vendored" libraries to avoid this kind of dependency conflict. (As a side note, the Samba project maintains talloc so I don't blame them for wanting to bundle it.)

What the netatalk3 port maintainer has done to work around this issue is to disable Spotlight functionality. Would this be an acceptable workaround for you too, or do you rely strongly on Spotlight in your deployment?

[andylemin]

I agree having the option to not bundle talloc in Samba is more consistent with best practices, especially when it means deploying .so's into common locations.

And Spotlight is definitely desirable, especially for large shares.

Maybe you could give both Samba and FreeBSD teams a nudge and see what they think? Ideally it should be changed on Samba/upstream side as this is probably not limited to FreeBSD.

[rdmark]

Interestingly, the FreeBSD port installs "private" shared talloc libraries for Samba:

$ find / -name libtalloc* 2> /dev/null
/usr/local/lib/samba4/private/libtalloc-report-samba4.so
/usr/local/lib/samba4/private/libtalloc-report-printf-samba4.so
/usr/local/lib/samba4/private/libtalloc-samba4.so

And, the samba binary itself has the RUNPATH flag set by the linker to hard code it to these libraries:

$ objdump -x /usr/local/sbin/samba | grep 'R.*PATH'
  RUNPATH      /usr/local/lib/samba4/private

Ergo, I don't see a reason why samba419 should conflict with talloc.

I can try to contact the port maintainer, sure. It might be even better if you contacted them too, since you're an actual end user who is negatively impacted, so you would have a very concrete story to tell them. Something for your consideration.

[andylemin]

Makes sense for the main talloc libraries to be privately linked, otherwise it would be a bigger issue.

You can do the same for python libraries as well, so I wonder why that one is different. Sounds like a simple omission maybe.

Sure, I'll try and send a message as well this week 🙂

[rdmark]

A week later, and the samba419 port maintainer hasn't responded yet to a direct email, unfortunately...

I wonder if there's another forum for getting traction for this question?

[andylemin]

Hi,I also emailed him, and he’s not replied to me either sadly.I’m not on any FreeBSD mailing lists, but I’m sure there are some. If I find time between day-job, I’ll join one and re-raise the topic. Thanks for the nudgeOn 4 Aug 2024, at 16:41, Daniel Markstedt ***@***.***> wrote: A week later, and the samba419 port maintainer hasn't responded yet to a direct email, unfortunately... I wonder if there's another forum for getting traction for this question? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[andylemin]

Posted on FreeBSD-ports@ 🤞

[rdmark]

I took the liberty of converting this to a Discussion. As mentioned above, I strongly believe this a downstream packaging issue rather than a bug in Netatalk per se...

Hopefully we can get a response from FreeBSD folks soon!

[rdmark]

Mikael got back to me moments ago and shared that this is being worked on: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280557