Patch to remove zlib.
abartlet at samba.org
Sun Jul 13 22:02:11 MDT 2014
On Fri, 2014-07-11 at 07:53 -0400, Ira Cooper wrote:
> On Fri, Jul 11, 2014 at 4:54 AM, Volker Lendecke <Volker.Lendecke at sernet.de>
> > 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.
Just summarising my other mail, but can you indicate both what you want
done and WHY we should do it?
> 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.
> 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
> 5. ctdb, tdb, tevent* - Given the active development by the Samba Team on
> these libraries, and that we are the main consumer, I think breaking these
> out is not a good idea.
> 6. Everything else. Likely it is not ready to be broken out. There may be
> technologies we wish to consider breaking out, but I don't consider that
> part of this section of the project.
> People have convinced me personally that talloc CAN be broken out
> successfully, or that the experiment may be worth trying. The rest, given
> the recent re-importing of ctdb, I think breaking out ctdb is not real
> likely to work. Libraries should have a good number of external users that
> are willing to contribute to them, or they should be so stable, that we are
> surprised when we see a commit in that area, IMHO.
> talloc passes. The rest do not.
> And honestly, there may be technologies we wish to break out, like pidl,
> etc. This pass, does not deal with those. Let us break the work down into
> doable chunks.
> I'm going to submit a patchset that conditionalizes zlib, as you requested,
> and goes a step further and lets the AD DC build with it conditionalized.
> Then iniparser. (Which if someone wants to replace with code that does not
> suck, I'll let that person do. Frankly, anything that moves us closer to
> not using it is a win.)
> Then popt.
> Then I think we have a moment of contemplation, on socket_wrapper and
> Another on talloc, (which I may not be the person who removes. Because
> that is really about setting up the talloc project, which I may be the
> wrong person to do.)
> The rest, I have real concrete objections to and I recommend the team not
> to do at this time. But, I realize my voice is one among many.
In doing this, please do consider what perverse incentives you may be
creating with the precedent, and if a useful goal is achieved compared
with a massive on-list discussion.
Also ensure any proposal fully considers autobuild, the build farm and
tools for our users (eg the install_with_python.sh script)
> PS: From here on, I will be pushing to a git repo for these patches, I like
> all your e-mail boxes too much to submit another patch this size to the
Please post git links if you wish to have an on-list discussion.
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
More information about the samba-technical