[Pkg-samba-maint] talloc packaging as an example of multi-pyversions package

[Michael Tokarev]

11.04.2022 00:17, Andrew Bartlett wrote:
> On Sun, 2022-04-10 at 11:36 +0300, Michael Tokarev wrote:
>> As I wrote in the previous email: it is samba :)
>> For python3-samba package there's one extra rdep,
>> freeipa-client-samba.
> 
> Given this, was the detour via multi-version Samba entirely avoidable,
> or would it be useful still if we could make it work for Samba?

I don't think there's any actual need to build samba or related
libraries for multiple python versions. There's just no point in
doing that.

More: it looks to me that samba can stop providing externally-visible
python bindings for its support libs completely, given just the
popularity of these. Yes that's wrong thing to do (or actually not
to do), but just by popularity of these, there's no reason to
provide them.  That same python-ldb can be easily swallowed by
the python-samba in debian, and python-tdb & python-talloc can
be built during samba build only, not during tdb & talloc build.
Again, still not a right thing (a library should come together
with its bindings for other languages), but speaking just by
the popularity of these bindings.

And since there's no external-to-samba packages which use
these python bindings, there's no big deal in providing
the bindings for multiple python versions, either.

Please excuse me for starting this whole theme. Initially
I *thought* there are many external users of python3-talloc,
but I was wrong, - these are the users of talloc, not its
python bindings. The whole theme is moot.

> The reason I ask is that I think we could, if needed, create a Samba
> that only publishes python modules, but doesn't link to python.

That one I don't understand :) Not linking to python modules..

Actually this very thing was puzzling for me. So far, samba
is the only package in Debian which uses python modules as
C libraries, so that it is possible to link a python module
with/from a C program. This is why all that symbols file
generation is there, - Debian infrastructure does not
provide means for this file to be dynamic, it is entirely
static in all other places.  I tried to find one other
single example of a similar situation, where a package
provides C bindings for a python module (not the other
way around), and found nothing so far.

> The only part of Samba that is not a python module or helper for a
> python module is source4/param/provision.c in support of smbtorture via
> the libnet_Vampire() code.  We could add a --without-smbtorture build
> to kill two birds with one stone, killing the testsuite (while keeping
> it for the RH folks who seem to want it installed) and killing the
> dependency.

That might be a good thing, yes. Assuming I understood
what you're talking about. I'm not yet familiar with
the samba internals.. :)

I had 2 questions which started this. First was a way to
provide multi-python-version of the python bindings, which
turned out to be unnecessary (and even turned out to show
that whole python bindings aren't useful, it all can be
part of python-samba just as well).

And second was whenever smbtorture (samba-testsuite package)
is in any way useful to provide a separate package for it.
I still don't know how one can use it and why do we build
it on debian, and why upstream samba builds it in the first
place *too*.  Dropping it from debian would be a very nice
cleanup. But after the RH response I don't think it is
a good thing to do.

Thanks!

/mjt