lib_3p system

Ira Cooper ira at
Wed Jul 16 19:42:59 MDT 2014

On Wed, Jul 16, 2014 at 8:36 PM, Jelmer Vernooij <jelmer at> wrote:

> On Wed, Jul 16, 2014 at 07:03:55PM -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:
> >
> >;a=shortlog;h=refs/heads/lib_3p
> >
> > 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.)
> Can you rename it to something with a more obvious name? "p3" doesn't
> mean anything to me. Perhaps "lib/external" ?
> Please update lib/, which is there to update
> some of these libraries. (I've got a pending patch to make it update zlib)
> Can you move each library in a separate commit? Git doesn't deal well
> with moves of lots of files unless you specify the magic options (see
> e.g. the output of "git log lib/zlib").

lib_3p stands for "Libraries, Third Party." "external" is a bit too vague
for this use.  I really want an exact meaning.

As far as what I really intend, it was clear I missed a bit on my real

Look at;a=summary ; and you'll see
the missing piece.

The intent is that there is a second git repo, and that all of this data is
properly kept under SCM.

The intent of the tarball is only for discussion, because I didn't have the
git repo ready yet.

I expect 2 tarballs would be distributed in reality for a release:


I got to learn git filter a bit.  I'd expect someone like metze, vl or one
of the true git heads, could actually get it 100% right, the tags are
missing.  It'd be nice to have them.

(I have a repo with the remote tags right, but I don't know how to turn
them into locals... so if someone can get me that command, I can push the

Do NOT assume lib_3p is fully stable yet based on the above.  But...
hopefully it will help communicate the goals better.



More information about the samba-technical mailing list