[Pkg-samba-maint] Library handling in the Samba 4.0 package

[Andrew Bartlett]

On Sat, 2013-09-07 at 20:36 +0200, Ivo De Decker wrote:
> Hi Jelmer,
> 
> On Sat, Sep 07, 2013 at 05:48:15PM +0100, Jelmer Vernooij wrote:
> > After the change to add sonames to the private libraries,
> > dpkg-shlibdeps now generates proper dependencies for all shared
> > libraries. The consequence of this is that we now have circular
> > dependencies between most of the packages.
> > 
> > This is a mess that is (almost?) impossible to untangle. And with this
> > amount of circular dependencies, it is pretty much pointless to have
> > separate binary packages anyway - you'll always end up installing all
> > packages anyway.
> 
> Indeed. This is also why I didn't try to prepare an upload after I imported
> samba 4.0.9 into the repo.
> 
> > So I'd like to suggest sticking all libraries in a single package for
> > the time being. That package will be large, but not huge. It is also
> > no worse than what we do at the moment, and it allows us to move
> > forward.
> > 
> > If there is a need to split a particular library out into a separate
> > package, because there is something else that needs just that library,
> > we can still move it outside of samba-libs when we want to.
> > 
> > Thoughts? Peanuts? Rotten tomatoes?
> 
> We talked about this at debconf, and this is what we came up with (I'm writing
> from memory, so this might not be 100% correct):
> 
> - Samba and samba-ad-dc should be moved into 1 package (called 'samba'), which
>   ships smbd, nmbd and the samba daemon. It should behave as an samba 3-style
>   server by default, with the option to configure the samba 4-style ad dc
>   manually.
>   It would be nice to have debconf questions to configure the ad dc
>   automatically (based on the scripts currently in the ad-dc package), but
>   that probably shouldn't be a blocker for the upload to unstable.

This seems reasonable.  The current design started mostly in response to
the historical layout, but also because I wanted to try and allow
installation of the file server only, such as on a NAS with constrained
flash. 

> - The libraries should be moved into a smaller set of packages, but it is
>   unclear how this can be done. Ideally, clients (like smbclient) shouldn't
>   pull in all the libraries needed for the servers.

Samba internally doesn't make this easy.  'client' libraries require a
lot of what you would think is server code.  For example, we support the
registry smb.conf backend, so anything that touches loadparm (which is
everything) needs the registry.  Similarly for gensec and other things.

> It's clear that splitting the libraries will be very difficult. So if you
> think this is not realistic at this point, I don't mind if all the private
> libraries get merged into one big library package. Go for it!

This seems the most reasonable approach at the moment. 

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Catalyst IT                   http://catalyst.net.nz