[1/2] samba: deprecate package due to EOL

Samba 3.6.x is now EOL, people should move to samba4.

See: https://www.samba.org/samba/history/samba-4.2.0.html

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/samba/Config.in | 2 ++
 1 file changed, 2 insertions(+)

On 05/03/15 21:44, Gustavo Zacarias wrote:
> Samba 3.6.x is now EOL, people should move to samba4.

 What about samba support in mpd and kodi?

 Regards,
 Arnout

> 
> See: https://www.samba.org/samba/history/samba-4.2.0.html
> 
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
> ---
>  package/samba/Config.in | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/package/samba/Config.in b/package/samba/Config.in
> index 9d04851..7ff8428 100644
> --- a/package/samba/Config.in
> +++ b/package/samba/Config.in
> @@ -1,5 +1,6 @@
>  config BR2_PACKAGE_SAMBA
>  	bool "samba"
> +	depends on BR2_DEPRECATED_SINCE_2015_05
>  	depends on BR2_TOOLCHAIN_HAS_THREADS
>  	depends on BR2_USE_MMU # fork()
>  	depends on !BR2_nios2 # binary too large, relocations don't fit
> @@ -15,6 +16,7 @@ config BR2_PACKAGE_SAMBA
>  		so choose only the components you need.
>  
>  comment "samba needs a toolchain w/ threads"
> +	depends on BR2_DEPRECATED_SINCE_2015_05
>  	depends on BR2_USE_MMU
>  	depends on !BR2_TOOLCHAIN_HAS_THREADS
>  
>

Dear Arnout Vandecappelle,

On Thu, 05 Mar 2015 22:53:35 +0100, Arnout Vandecappelle wrote:
> On 05/03/15 21:44, Gustavo Zacarias wrote:
> > Samba 3.6.x is now EOL, people should move to samba4.
> 
>  What about samba support in mpd and kodi?

And gvfs.

Thomas

On 05/03/15 23:06, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
> 
> On Thu, 05 Mar 2015 22:53:35 +0100, Arnout Vandecappelle wrote:
>> On 05/03/15 21:44, Gustavo Zacarias wrote:
>>> Samba 3.6.x is now EOL, people should move to samba4.
>>
>>  What about samba support in mpd and kodi?
> 
> And gvfs.

 But that's just a condition on the .mk file so it has no implications for the
missing reverse dependencies.

 Regards,
 Arnout

Dear Arnout Vandecappelle,

On Thu, 05 Mar 2015 23:10:56 +0100, Arnout Vandecappelle wrote:

>  But that's just a condition on the .mk file so it has no implications for the
> missing reverse dependencies.

Absolutely. But it means that the gvfs Samba support becomes unusable.

Thomas

On 03/05/2015 07:23 PM, Thomas Petazzoni wrote:

> Dear Arnout Vandecappelle,
> 
> On Thu, 05 Mar 2015 23:10:56 +0100, Arnout Vandecappelle wrote:
> 
>>  But that's just a condition on the .mk file so it has no implications for the
>> missing reverse dependencies.
> 
> Absolutely. But it means that the gvfs Samba support becomes unusable.

There's no pretty way out of this, the 3.6.x codebase is going
completely unmaintained upstream.
It's basically sheer luck that upstream fixed CVE-2015-0240 (which is
pretty severe) on the 3.6.x branch, just because 4.2.0 was delayed.
The best solution i can think of is either use samba 3.6.x as a fallback
libsmbclient (not very nice looking forward) or switch everything to
samba4 with the added size and restrictions.
kodi and mpd aren't small so i don't think it should be a deciding
factor, gvfs is meh, but then it's optional.
I'd favor the 2nd option.
Another factor to consider is that eventually (maybe already) the old
libsmbclient won't be able to talk to newer windows servers anyway,
specially when older versions of the protocol are disabled for security
reasons.
Regards.

Dear Gustavo Zacarias,

On Thu, 05 Mar 2015 21:11:22 -0300, Gustavo Zacarias wrote:

> There's no pretty way out of this, the 3.6.x codebase is going
> completely unmaintained upstream.
> It's basically sheer luck that upstream fixed CVE-2015-0240 (which is
> pretty severe) on the 3.6.x branch, just because 4.2.0 was delayed.
> The best solution i can think of is either use samba 3.6.x as a fallback
> libsmbclient (not very nice looking forward) or switch everything to
> samba4 with the added size and restrictions.
> kodi and mpd aren't small so i don't think it should be a deciding
> factor, gvfs is meh, but then it's optional.
> I'd favor the 2nd option.
> Another factor to consider is that eventually (maybe already) the old
> libsmbclient won't be able to talk to newer windows servers anyway,
> specially when older versions of the protocol are disabled for security
> reasons.

Switching everything to Samba 4 is fine for me: that's the upstream
decision, and in Buildroot we generally try to follow upstream
decisions. If people are unhappy with Samba 4 being much bigger than
Samba 3, then it's up to them to work with the Samba folks upstream to
solve this. One guy posted some Buildroot patches at some point to only
install certain parts of Samba 4 to reduce the installed size, and we
invited him to work with upstream to resolve this.

So in my side, I'm fully OK with a solution that consists in switching
kodi, mpd and gvfs over to Samba 4.

Best regards,

Thomas

On 03/06/2015 05:19 AM, Thomas Petazzoni wrote:
> Switching everything to Samba 4 is fine for me: that's the upstream
> decision, and in Buildroot we generally try to follow upstream
> decisions. If people are unhappy with Samba 4 being much bigger than
> Samba 3, then it's up to them to work with the Samba folks upstream to
> solve this. One guy posted some Buildroot patches at some point to only
> install certain parts of Samba 4 to reduce the installed size, and we
> invited him to work with upstream to resolve this.
> 
> So in my side, I'm fully OK with a solution that consists in switching
> kodi, mpd and gvfs over to Samba 4.

Just to document for people: The problem is that the libsmbclient
library is pretty much connected with many of the other libraries, you
just can't build that library alone and expect it to work.
And for samba4 it's not binary (as in /usr/bin/* & /usr/sbin/*) size
that bloats since all common code was moved to libraries.
With the new smbtorture option (the one and only big binary) i think
it's not worth the effort, specially that python is being pulled in and,
again, it's pretty wired into the samba4 build system hence hard to avoid.
Regards.