Disabling python modules.

[Jeremy Allison]

On Fri, Jan 06, 2017 at 07:06:09AM +1300, Andrew Bartlett wrote:
> On Thu, 2017-01-05 at 08:59 -0800, Jeremy Allison wrote:
> > That's the key. Embedded vendors wanting only smbd or the client
> > libsmb or net tools simply don't need the python modules, and it
> > makes buiding
> > Samba on these systems really hard (to the point where some give up
> > and use alternatives, and we really don't want to see that :-).
> > 
> > I don't think allowing these fixes will have any effect on how
> > we use python for our "full" installations (tooling etc.) - after
> > all our build system is python so it's not like we're going to
> > reduce use of it.
> 
> As long as that is the rule I don't mind folks cutting out features. 

+1 on that.

> However they should know we don't promise (within reason) how limited
> that feature set is, eg if someone has a burning desire to rewrite one
> of the tools as a python wrapper, or write a new tool that way, I would
> really not like to hear 'but the embedded vendors...'. 

I don't think that is a concern. If a tool gets rewritten the
old code is still available to embedded vendors even after we've
removed it from our codebase (and I think moving from C -> python
or C -> rust or even C -> go is in our future :-).

I found out only today that the reason that the media player
Kodi reports bad SMB performance for their users and recommends
NFS is that they are still using the libsmbclient from 3.0.x days
as they want to ship common code on iOS (where the Apple App store
prohibits GPLv3 code). Religious zealots... (sigh).

Still give us a bad rap though (SMB is *sloooowwww*), which
pisses me off no end.

Why they they don't make it pluggable to allow their users to
decide to upgrade to a modern performant libsmbclient is beyond
me.