transitioning release management

Andrew Bartlett abartlet at
Thu Feb 28 09:12:45 GMT 2008

On Thu, 2008-02-28 at 08:36 +0100, Volker Lendecke wrote:
> On Wed, Feb 27, 2008 at 04:32:08PM -0500, simo wrote:
> > > The big change is that instead of the user manipulating structure
> > > members in the context structure, the context structure will become
> > > entirely opaque, and setter and getter functions will be used for
> > > changing it.  This allows me to make changes to the internal context
> > > structure, typically for adding new functionality, without affecting
> > > the ABI.  While I'm at it, I'll clean up the use of the different
> > > types of option settings (there are currently three different
> > > mechanisms in use!) and the authentication callback function.
> > 
> > This sounds reasonable, but to be honest I'd like to gain something from
> > breaking API/ABI. Breaking API/ABI means distributions may need to carry
> > on a libsmbclient-compat package, so it's better if the difference
> > between the 2 is because of functionality change and not just interface.
> Yes, I'd also like to know what we would gain from it. If it
> is just the order of struct members in _SMBCCTX and some
> ugliness for setting options, then I'd say it's not worth
> it. Can you describe in a bit more detail with pointing at
> concrete source file lines what you would like to fix?

It certainly would be a pity to break apps or require -compat packages
on systems, which means that security fixes need to be applied to Samba
3.0 code well into the life of 3.2, because it will still be

A second API alongside of course would not suffer this, but would also
not help the original problem, being the presence of an ugly interface. 

Andrew Bartlett

Andrew Bartlett
Authentication Developer, Samba Team 
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :

More information about the samba-technical mailing list