[Pkg-samba-maint] Bug#571635: Bug#571635: samba: Should provide headers for libraries development.

[Jelmer Vernooij]

On Sat, 2010-02-27 at 20:01 +0300, Al Nikolov wrote:
> On Saturday 27 February 2010 17:06:33 Jelmer Vernooij wrote:
> > Unfortunately there is no stability in the internal Samba 3 API's, so I
> > don't think it we should just blindly install these headers.
> It's not very clear either which headers are absolutely internal.
They're all internal, except for talloc, tevent and tdb.

> > At the very least, what is installed should be limited to those headers
> > that are relatively stable. Samba 4, talloc and tdb headers should be
> > excluded since they're already packaged elsewhere.
> Samba4 headers have been already excluded in my patch.
> 
> talloc - i agree (it's only 2 headers).
> 
> tdb? It seems to me that your own samba package don't build-depend on tdb-dev.
Yes, but there's no point for external users in building against the  
 Samba tdb headers since there are no tdb libraries shipped in the
 samba binary packages that they could link against.

> > A perhaps saner solution would be to have upstream install those headers
> > that are stable and necessary for building modules rather than trying to
> > figure out what that set is on our own.
> Unfortunately the unconfigured Samba tree haven't headers needed.
> 
> Samba guys have a POV on how to develop a Samba module: it has to be 
> considered as a part of Samba. Do we both have a willing to build another 
> module binary package from src:samba? I'm in doubt.
Are you sure that is our official policy ? Or is it simply that nobody
has put the effort in yet to separate out a set of public headers that
we could decently support?

> I've worked out which headers have been actually used recursively 
> during my own module build and therefore reduce the number of headers. The 
> overall number of headers in the proposed samba-headers package was 389. 
> During my module build 217 of these have been included.
> 
> Not sane, you say. Perhaps, it's not so sane to just `find & install` almost 
> all headers and then `find & -I@` include directories, but (1) it works, (2) 
> there isn't any smart way to do that (thanks, Samba!), and (3) i see no harm 
> in this solution comparing it to yours.
This solution will likely break your modules when a newer version of
Samba gets installed, since there are no API guarantees whatsoever. 

We don't want to provide these headers in a package because we can't
provide an upgrade path for users between versions of the samba-headers
package. 

> Probably, i can reduce the number of the headers installed by 45% from my 
> latest patch, but should we expect this set will be the same in the next 
> minor Samba3 release? And if so, what was your clams about "non-stable API"?
Functions and data structures get added, changed, removed between Samba
minor releases. Some API's are more prone to this than others (we try to
not change the VFS API unless really necessary for example). 

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-samba-maint/attachments/20100227/5b8fd32f/attachment.pgp>