31.03.2022 22:18, Andrew Bartlett wrote:
On Thu, 2022-03-31 at 18:54 +0300, Michael Tokarev wrote:
$ dpkg -L samba-libs | grep python libsamba-policy.cpython-39-x86-64-linux- libsamba-policy.cpython-39-x86-64-linux- libsamba-net.cpython-39-x86-64-linux- libsamba-python.cpython-39-x86-64-linux-
Samba's libsamba-net.cpython-38-x86-64-linux-gnu-samba4.so is indeed a normal library linked to by other bits of Samba that links to python (it opens python modules and runs them). With some work that could possibly be removed for a production build, the use case ends up only being smbtorture, but currently it is the case.
Aha. This is the package which I didn't check, - smbtorture (samba-testsuite package). I grepped for these modules in all binary packages, but I removed some of them (*dbgsym*) which are not relevant, before doing this. And I removed the samba-testsuite.deb *too*. Okay. This should be easy to solve. Actually, it is _already_ solved: in the new build with the above 3 libs moved to python3-samba, samba-testsuite package has Depends on python3-samba. That takes care of it all, I think, - the move worked just fine even if I didn't find smbtorture dependency. Neat :) FWIW, I haven't actually looked how smbtorture uses this lib. But if it's some python binding or a way to call python from samba, does smbtorture actually use any python code? If so, why it does not depend on any python bits? And if no, why it links to this lib? :)
So moving those around would not change the resulting dependencies unless one was very careful.
I'm not sure I follow you here. Apparently it all just works :) I just pushed the commit which moves 3 libs, to master. I added a note to the commit comment mentioning smbtorture. /mjt
