Disabling python modules.

ronnie sahlberg ronniesahlberg at gmail.com
Thu Jan 5 18:28:48 UTC 2017


On Thu, Jan 5, 2017 at 10:13 AM, Jeremy Allison <jra at samba.org> wrote:
> 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).

Well,   that is their right to chose what licence they want to use.
This is also what prevents QEMU from having a built-in SMB client,
something which all
other, commercial, alternatives have. With the end result that the
linux open source
virtualization to lack in featureset.

Be happy though that folks like QEMU respects the licence and thus
decide to ship product
that is lacking in features.

This list is not the right place for religious discussions though.

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

Non-GPLv3 SMB client is slow. That is a fact.
GPLv3 SMB is probably very fast but a lot of people can not use it.

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

I have better idea.
I write SMB2 client that is lgpl2.1 so that QEMU can reach feature parity with
all other virtualization products.

Anyone want to help?



More information about the samba-technical mailing list