[Pkg-samba-maint] [SCM] Debian packaging for Samba branch, samba_4.0_bubulle, updated. upstream/4.0.5+dfsg1-789-gda57358

[Ivo De Decker]

Hi Christian,

On Sun, May 19, 2013 at 09:40:27AM +0200, Christian PERRIER wrote:
> > My preference would go for samba. Though these are techically speaking
> > libraries, one could argue they are so very closely related to samba
> > FPS daemons that it's better to provide them altogether.
> 
> Also : the VFS modules were originally provided in samba in 3.6
> packages. So that change is part of our current policy to not move
> files around between packages in the 3.6->4.0 transition.

Well, that depends. If there is something else (other than smbd) using the vfs
modules, they could need to be in a different package (like libsmbd0). But I
don't think that's the case.


There are a number of issues with the dependencies between the libraries (this
was also reported as #693576 against samba4). Most dependencies are not
automatically generated. There is currently at least 1 circular dependency
between samba-common-bin and python-samba. Autogenerating all the required
dependencies would certainly create more. To solve this, some things may need
to be moved around. Also, I don't know how we could generate these
dependencies the right way. We should generate symbols files for all public
libraries, but this doesn't solve the problem for the private ones.


Currently, the vfs_dfs_samba4 is build as a static module (the waf build does
this by default if the AD DC build is enabled). This means that smbd links
(through libsmbd0) against dfs_server_ad, which is shipped in the samba-ad-dc
package. If this dependency would be correctly specified, it would also be
circular (as samba-ad-dc depends on samba). We could build vfs_dfs_samba4 as a
dynamic module and ship it in the samba-ad-dc package (I don't think it makes
sense without the AD DC), but I haven't investigated this yet.


Cheers,

Ivo