Difficulties bringing waf15 updates into Samba (was: Re:?[PATCH]?build scripts enhancements)

[Michael Adam]

On 2015-06-26 at 23:30 +0200, Thomas Nagy wrote:
> On Fri, 26 Jun 2015 19:51:56 +1200, Andrew Bartlett wrote:
> 
> > On Fri, 2015-06-26 at 07:52 +0200, Thomas Nagy wrote:
> > > On Fri, 26 Jun 2015 12:28:05 +1200, Andrew Bartlett wrote:
> > > 
> > > > On Fri, 2015-06-19 at 18:36 +0200, Thomas Nagy wrote:
> > > > > Please apply the patches attached to this message and
> > > > > update your Waf 1.5 copy from the source repository
> > > > > https://github.com/waf-project/waf.waf15
> > > > > 
> > > > > Thomas
> > > > 
> > > > If we update waf again, we currently have to keep the
> > > > local patch to python.py
> > > > [...]
> > > > Do you have any thoughts on a better way to do this?
> > > > 
> > > > We also can't import the whole waf tree, or carry it as a
> > > > submodule, as that would bring in waf/doc/book which is
> > > > non-free.  (Carrying that would cause all distributions,
> > > > not just Debian, to then have to expunge it from our
> > > > tarball, and may even cause issues with our obligations
> > > > to our fiscal sponsor, which strictly requires that Samba
> > > > distributes only free software).
> > > 
> > > Are the new git submodules in Samba causing some confusion?
> > 
> > We are talking about, but not using submodules.  We have
> > started to mirror the git repos we would use, so we don't get
> > caught out when external hosting services change. 
> 
> My bad, I did not understand the submodule situation. Yet, this
> will not be a problem any longer; the files in attachment will
> apply directly to the Samba tree. The last new ones represent
> another important step towards the Waf 1.8 API usage.
> 
> > Either way, it would be most helpful if you could assist us with
> > liberating the non-free docs.
> 
> I realize now that this would not only be useless - there has
> never been any need to copy the BSD documentation to the Samba
> tree - but also counter productive. The update script is very
> coarse

Right, we could simply filter the docs from being
copied. This does not seem to be a real issue to me.

> and has already lead to poorly reviewed modifications.

E.g. ?

> It is actually much better to have every buildsystem changes
> follow the same review model as any other for the Samba tree.

Our goal is to reach a state where we use an unmodified
upstream version. Hence the move to third_party and the current
discussion about submodules. We only want to have control
over which exact state of upstream we take.

> This might add some verbosity to the mailing-list, but this is
> a small sacrifice to pay for build stability after all.

Please see my other mail in this thread which disregards
the doc-license issue and makes proposals as to how
to proceed with this.

Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150627/0ff915a2/attachment.pgp>