Patch to remove zlib.
ira at samba.org
Fri Jul 11 08:27:23 MDT 2014
On Fri, Jul 11, 2014 at 10:15 AM, Stefan (metze) Metzmacher <metze at samba.org
> Am 11.07.2014 13:53, schrieb Ira Cooper:
> > On Fri, Jul 11, 2014 at 4:54 AM, Volker Lendecke <
> Volker.Lendecke at sernet.de>
> > 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
> >> 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
> > 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
> > 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
> > a library we maintain, that we can break out. I personally think talloc
> > 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/librelease.sh 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.
I'm open to other opinions on talloc, and it should be an open discussion.
As you move down the list, I assumed the chances of removal went down,
lower and lower :).
More information about the samba-technical