Patch to remove zlib.

Ira Cooper ira at samba.org
Fri Jul 11 08:08:38 MDT 2014


On Fri, Jul 11, 2014 at 9:57 AM, Stefan (metze) Metzmacher <metze at samba.org>
wrote:

> Am 11.07.2014 15:43, schrieb Jelmer Vernooij:
> > Hi Ira,
> >
> > Thanks for taking this on.
> >
> > On Fri, Jul 11, 2014 at 07:53:04AM -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.
> > What do you mean with technically feasible? Do you mean when it is
> technically
> > feasible to build Samba with the system version of these libraries?
> > That is already possible at the moment for all four.
>
> >>  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.
> > It already is possible to build a working AD DC without the bundled
> > Heimdal, using the system Heimdal. We do this for the Debian/Ubuntu
> packages,
> > and Samba has supported this for a long time.
>
> But there're still some patches only in our copy of heimdal.
>
>
> https://git.samba.org/?p=lorikeet-heimdal.git;a=commitdiff;h=70a1b4d8eb710e15ff7a1c8068500dd62f3a3426
>
> https://git.samba.org/?p=lorikeet-heimdal.git;a=commitdiff;h=f307cd00f4b14cf14f6fcae9c93378967972a15d
>
> And looking at
>
> https://git.samba.org/?p=abartlet/lorikeet-heimdal.git/.git;a=shortlog;h=refs/heads/lorikeet-heimdal-201402190928
> show a few more.
>
> The external heimdal versions are also not verified to work completely.
> The last import attempt failed because something broke and didn't pass our
> tests anymore.


Pardon, I missed part of Jelmer's reply.

Removing Heimdal is not technically feasible at this time.  Why?  Because
we don't have a functioning AD DC without our patched Heimdal.

As soon as there is a library that meets the AD DC's needs.  (Be it a
version of Heimdal, or MIT Kerberos.) I believe the removal of Heimdal is
viable.

But I put it with the first 3 libraries because I believe it is not
something we have any real interest in maintaining, it "belongs" to someone
else.

-Ira


More information about the samba-technical mailing list