On Thu, 2022-11-10 at 16:44 +0300, Michael Tokarev wrote: > > But samba-libs needs to be split further, into something like > samba-common-libs, > samba-client-libs, and so on. This way, we may have some of them independent > on > the kerberos implementation used - say, samba-common-libs, whicih can be used > by both heimdal-using samba server packages and mitkrb5-using smbclient.
The Samba Team will never support an install of Samba that is built up of parts built with different options. > Or alternatively, another set of samba-libs - ie, another package of > samba-libs, > say, samba-libs-mitkrb5 - needs to be created. This quickly becomes rather > ugly and unmanageable. > > I think the only more or less realistic way to go is to split samba-libs into > subcomponents. Actually, samba-common-bin and samba packages also needs to > be split further into multiple pieces. For example, that needs to be > samba-ad-dc, samba-ad-dc-provision (for /usr/share/samba/setup/*), maybe > samba-krb5-printing, maybe python3-samba-ad-dc (from python3-samba) and > so on. This is not a huge work really, but it needs to be done in order > to allow to mix and match things. I can only strongly advise against mix and match. > Besides, I implemented pkg.samba.mitkrb5 build profile for samba package, > maybe this one will help somehow. But it builds everything with mit-krb5, > including the experimental ad-dc code. This is the only approach, a separate build profile. If there is the motivation, the user could be allowed to install one suite or the other I guess. Andrew Bartlett -- Andrew Bartlett (he/him) https://samba.org/~abartlet/ Samba Team Member (since 2001) https://samba.org Samba Developer, Catalyst IT https://catalyst.net.nz/services/samba
