Re: [PR PATCH] [Closed]: Samba 4.13.2

[ahesford <ahesford@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]

There's a closed pull request on the void-packages repository

Samba 4.13.2
https://github.com/void-linux/void-packages/pull/27166

Description:
This is an attempt to resolve the outstanding issues in #17544 and bring Samba up to date. Regarding the issues described in that PR:
1. `sssd` is bumped
2. I removed `libwbclient` from `sssd` some time ago because we weren't doing it right anyway. No conflict remains.
3. I have removed most of the private libraries by telling Samba to build these into the public libraries. This seems preferrable than having a horde of private libraries that still have to be tracked for shlib dependency resolution, or else break resolution for all dependants. Unfotunately, not all private libraries can be built in without breaking the samba build, so we still have a few unversioned `*-samba4.so` shared objects to keep track of.
4. `common/shlibs` is properly arranged given the current package configuration.
5. I do not think there is great value in splitting samba *ad infinitum* like Alpine does. I have, however, taken some inspiration from Alpine in where subpackages contents are divided.
6. I have fixed the Python extension build process where necessary so that Python libraries have a `.so` extension rather than a `.cpython<arch-specific-garbage>.so`, so no problem here.
7. I have enabled the Python packages, but AD Domain Controller functionality is marked as experiment when used with system `krb5`, so I've left that disabled. However, the groundwork is laid for a future update where things are not experimental.

Also, everything properly uses `qemu-user-static` and the `--cross-execute` capability of `waf`, rather than relying on `cross.answer` files everywhere.

I have mostly followed tried to honor the existing subpackage structure, although there are some changes.
1. The `samba-cups` package has been replaced by `smbclient`, which assumes responsibility for `smbspool`. The `-cups` package was nothing but a symlink to `smbspool` anywhere, so there is no need to separate it out.
2. Samba 4 expands the collection of "client" programs, so I've added more programs to the `smbclient` subpackage, taking inspiration from Alpine. I almost want to rename this `samba-clients`, but I'm not sure it's worth the trouble given that `smbclient` is a leaf package so we'd have to do a transitioal package anyway.
3. I've renamed `libsmbclient` to `samba-libs` and made it assume all of the core samba libraries used by both the clients in `smbclient` and the servers in `samba`. We could try to split this further, but there are a lot of interdependencies and I'm not sure it's worth the effort.

The new package seems to work for me, especially when using `smbclient` to browse Win10 hosts; this was not working with the existing package.