third_party (ex-lib_3p) now ready for review.

Andrew Bartlett abartlet at
Thu Jul 24 16:23:05 MDT 2014

On Thu, 2014-07-24 at 13:45 -0700, Jeremy Allison wrote:
> On Thu, Jul 24, 2014 at 08:39:15AM +0200, Stefan (metze) Metzmacher wrote:
> > 
> > Yes, I also prefer that. Having a 2nd git repository just makes sure
> > things get our of order.
> > Removing third-party/ from master gets a clear NACK from me.
> NACK on that NACK :-). I don't see any good
> technical reasons behind it. Especially as
> you propose a technical solution I agree
> with below :-).
> I think it's very important to remove third_party/
> from the tree. Removed code cannot be compiled in by
> error. Remember, the goal is to get Samba out
> of the third-party maintanence business (as
> we're just not doing it).

What I propose (having the tarball creation process strip these out)
also achieves the same goal. 

> It isn't as though we're maintaining or updating
> that code. Having it available as a separate
> git repository that people can pull, or as a
> separate tarball that we fetch is enough.
> > We can have the release script create an additional
> > samba-A.B.C-third-party.tar.gz
> > 
> > I think we should also have an autobuild target using
> > --bundled-libraries=ALL
> > to make sure we force the use of the third-party libraries to make sure
> > they're usable.
> +1 on having an autobuild target that fetches
> and builds against the samba-A.B.C-third-party.tar.gz
> libraries to ensure we will always build against it, but
> I *really* want these out of our tree.

The way I see it, if autobuild is still using it, if the build farm is
still using it, then it isn't out of our tree - it might be in a
different git repository, but we are still involved in work to ensure
they build, specifically including Samba wscript files. 

If we are still involved, then putting it in a distinct GIT repo only
creates work, and means we have to keep two different git repositories
in line.

What problem does moving these to a distinct git repo, that we still
have to maintain, solve?  

The arguments you make seem to be the arguments for just totally
removing all these external libs, including the build rules and
everything.  I see this as a distinct step, and one that still needs
some support for the build farm.

Finally, it seems we are putting far more effort into this than we ever
put into maintaining these libraries in the first place.

Andrew Bartlett

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

More information about the samba-technical mailing list