lib_3p system

Andrew Bartlett abartlet at
Wed Jul 16 18:09:44 MDT 2014

On Wed, 2014-07-16 at 19:03 -0400, Ira Cooper wrote:
> In all the work I've been asked for my rationale for the work I am done.
> It is about cleanliness and solid software engineering.  We can't be sure
> we AREN'T using libraries that are totally integrated into our build
> system.  While we can try, and we can claim, the true proof is removing
> them.
> In the interests of doing this, I've actually gone ahead and removed them,
> on a branch. and put in support for downloading a tar file, manually.
> The first patch on my new branch shows a file that was including our local
> popt headers, instead of following and finding the system ones.  I suspect
> it is the only one, but until there is more testing on more systems, I
> won't feel truly sure of that.
> If we wish to support a "fat" tarball for our releases, that is fine.  But
> for day to day to development, the intent of this change is to make it so
> developers who don't wish to have these libraries or their sources on their
> system, do not have them there.
> If you want more rationale than Simo's rationale, Jeremy's and Volker's, I
> suggest you look at my first patch on this branch.  It shows what I truly
> fear.  Insidious errors.  This error was innocent it looks like...
> thankfully.
> This is why I do not support third party libraries in the tree.  These type
> of mistakes are too easy to make, and too easy to tempt ourselves into.
> Git branch is at:
> The supporting "lib_3p" tar file:
>  (This should move to a better
> location and be versioned etc, if we do this.)
> I'll construct the actual git repo to go with the tarfile tomorrow.
> I suggest you look at the code, and the overall concept.  I think you'll
> find it a vast improvement, and a solid middle ground.
> (Yes, this is a request for review, and comments.)

gitweb seems very, very confused by this change.  Look at what happened
with: lib_3p/zlib/win32/Makefile.bor

The idea of clearly indicating which libraries are not from is
a good thing.  Being able to point the build farm at the full checkout,
but only release tarballs of the redacted source is also a really
interesting idea you should consider, as that won't disturb too much.
See samba_dist.DIST_BLACKLIST in wscript.

That is, I would suggest stopping at the creating of lib_3p, rather than
doing the git rm step.  That way we never have to do a security release
of a lib_3p library, because we never publish that tarball, the build
farm won't notice at all, and we can publish a 'fat' tarball with an
appropriate warning if there is genuine user demand. 

Andrew Bartlett

Andrew Bartlett
Authentication Developer, Samba Team
Samba Developer, Catalyst IT

More information about the samba-technical mailing list