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

[Andrew Bartlett]

On Sun, 2013-05-19 at 18:20 +0200, Ivo De Decker wrote:
> 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.

Why do we have that policy?  It seems silly to apply that to new library
packages crated by splitting things out due to the way the new build
system works, and the new things that depend on each other. 

> 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.

That is incorrect.  The reason these were intentionally put in libsmbd0,
on which samba must depend, is that the python bindings for libsmbd
(used by samba-tool ntacl) need the VFS modules.  libsmbd contains
almost the code for smbd.

> 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.

Why is that?

>  There is currently at least 1 circular dependency
> between samba-common-bin and python-samba. 

Why does python-samba depend on samba-common-bin?

> 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.

Yes, if we maintain samba-ad-dc as a distinct package, pdb_samba_dsdb,
auth_samba4 and vfs_dfs_samba4 should be shared modules. 

Finally in the TODO list, we need to ensure we don't ship manpages for
binaries we don't ship, like vfstest.1 (which we upstream stopped
suggesting for public consumption, it is a developer tool). 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org