Patch to remove zlib.

Stefan (metze) Metzmacher metze at
Fri Jul 11 08:15:46 MDT 2014

Am 11.07.2014 13:53, schrieb Ira Cooper:
> On Fri, Jul 11, 2014 at 4:54 AM, Volker Lendecke <Volker.Lendecke at>
> wrote:
>> On Mon, Jul 07, 2014 at 12:46:47PM -0400, Ira Cooper wrote:
>>> Note: To apply it  unxz it then use git am --ignore-whitespace ,
>> otherwise
>>> you may have issues.  (xz was used to save the list a good bit of
>> space...
>>> it's over 500k gzipped.)
>>> As far as why: I listened to metze/vl.  I disagree with them.
>> If we decide to remove zlib and make it a fixed external dependency we
>> should go the full path and apply the same to at least popt and iniparser
>> immediately. Next step then would be the wrappers, which are externally
>> maintained as well. Then after that comes our own 3 libs tdb, talloc,
>> tevent and possibly ldb. There's one big one that comes after that then,
>> but which should go as well: Heimdal. It's a slight change in policy,
>> but a valid one I guess.
> Actually, I have some of the code needed for the zlib removal done.  I
> think I'm missing a bit to make it conditional, for AD and the fileserver,
> but it I'm not far off.
> Then I have to do the waf parts etc, but still.. I'm hoping I can get it
> done today.
> As far as the rest of your points, I'm going to break the libraries into
> "groups" to be considered.  I personally have a line where I'll stop,
> because I think we have experience that shows where that line should be.
> 1. zlib, popt, iniparser, Heimdal - These libraries should be removed as
> soon as technically feasible.  The wording chosen IS intentional here.
>  Heimdal isn't possible today due to the AD DC, but when it IS possible to
> build a working AD DC without Heimdal, it no longer belongs in tree.
> 2. socket_wrapper - Given that we just put it in, we should stop briefly
> and think here.  I'm far from against it.  But to me, this is "more
> optional", than the first pass.
> 3. ntdb+ccan - I believe these should go.  But they are a separate issue.

I'm ok with that.

> 4. talloc - Talloc is stable, we aren't making changes to it.  If there is
> a library we maintain, that we can break out.  I personally think talloc is
> it.

I don't think we should split talloc. The reason is that maintaining
talloc, tdb, tevent and ldb is really easy to day.
Just changing the version number in the related wscript file
and pushing to autobuild. This makes sure everything passes the all
tests we currently have. The only talloc improvements in the last
time where driven by samba and while tunning for performance
it's easy to break something that won't be detected by only
running the standalone make test of tdb.

The release process is also very simple just 'script/ talloc',
entering 2 passphrases => done.

Given that everything is in one git branch, we don't have to maintain
multiple copies of waf or the release scripts.

I'd really like to keep it that simple.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the samba-technical mailing list