Patch to remove zlib.

[Michael Adam]

Hi Ira, Andrew, ...

I think Andrew has written a very valuable mail here.

In short, the yet unanswered main question is:

  What is the motivation to remove these libraries?

And more precisely:
- What would we gain?
- What would we lose?

A few comments:

- I think that, currently, we would lose more than we gain
  for the external libs (zlib, popt, iniparser, ...):
  These are bundled for convenience as options for the more
  exotic systems we still build on.

- For the libs that we produce ourselves (talloc, tdb, tevent, ...),
  I guess the main question is how much more work it would require
  to maintain these in a separate tree. And a very important
  point that Metze has already made deserves repetition:
  A commit to each of these libs is tested much more
  thoroughly by samba's autobuild than by the lib's selftest.

- ctdb is not a library, and the reason to move it into
  the tree was that this is not really an independent project
  yet, the client implementation being scattered across
  samba and ctdb code. So this needs to ripen before
  being reconsidered.

If we decide to remove (some of) those libs, shouldn't we for
convenience for the still supported more exotic platforms
at least create an extra repository (samba-portable or so)
that carries those convenience libs and sort of wraps the
samba repo, including build instructions(system/script)
to produce a samba build on most systems?
Modern Linux distros would get along with only samba core.

Finally let me remind the community of one earlier
rfc discussion to spin off our own libs into
separate repositories: see this thread:

https://lists.samba.org/archive/samba-technical/2008-June/059617.html

Cheers - Michael


On 2014-07-14 at 15:50 +1200, Andrew Bartlett wrote:
> On Mon, 2014-07-07 at 12:46 -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.
> > 
> > I believe that third party (non Samba Team developed) libraries do not
> > belong in the tree.  They are asking for trouble long term, IMHO.
> 
> > Consider this patch the first step down the path to cleaning up these
> > libraries.
> 
> Ira,
> 
> Can we step back a moment and describe what problem you are trying to
> solve?  In your initial mail, you said you did not want to carry it
> around for others to "step in", and here you say "They are asking for
> trouble long term, IMHO."  I can guess what you mean, but it would be
> helpful if you could express this in more detail, because we need to
> weigh that up against the reasons we included the libraries in the first
> place.
> 
> We currently have a practice of bundling libraries that we need, where
> they are helpful to have on systems we build Samba on, particularly
> those beyond the world of packaged Linux.
> 
> We have this practice for a number of reasons:
>  - the build farm is a very difficult environment to add additional
> dependencies on
>  - some consulting customers are particularly sensitive to installing
> additional software
>  - we have long prided ourselves on how portable Samba is, and that it
> 'just works' on a large number of systems.
> 
> However, the biggest reason we do this is to allow us to use external
> software libraries in core parts of Samba without first having a
> massive, unproductive argument on the list about the dis-merits of
> needing yet another library, and so yet again re-writing that component
> internally (because doing so is superficially easier). 
> 
> zlib and popt are both very stable, essentially unchanging elements of
> code.  Both have not had releases for years, and consume a tiny fraction
> of our tarball.  Having them always available does make our life easier.
> 
> The Reductio ad absurdum or straw man goes both ways:  Why don't we
> bundle a the C library also, or why don't we get rid of everything,
> including Heimdal, talloc and tdb.  The key here is getting the
> balance. 
> 
> As already discussed, making it optional just moves the problem from
> AIX/Solaris users to OpenChange deployments, probably involving just as
> many users, so this isn't reasonable. 
> 
> If it wasn't for the build farm, then I would be in favour of making
> zlib (but not pkg-config, or popt) a mandatory external dependency,
> given it is so very widely available.
> 
> If this was accompanied by patches to our build farm scripts to fetch
> and locally install zlib, then I could be persuaded to be in favour.
> 
> Finally, I'll note that at times like this it feels attractive to wonder
> why we try and be 'one big project', but I will say this:  These small
> pains are nothing compared with what we would endure trying to
> coordinate everything we do and the positive changes we continue to make
> as different projects. 
> 
> (I'll speak about some of the other proposals raised elsewhere in the
> thread.  )
> 
> I hope this helps,
> 
> 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
> 
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140716/7ea486ef/attachment.pgp>