Patch to remove zlib.

[Andrew Bartlett]

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>
> 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.

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
> it.
> 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
> ntdb+ccan.
> 
> 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)

> Thanks,
> 
> -Ira
> 
> 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
> list.

Please post git links if you wish to have an on-list discussion. 

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba