[PATCH] lib/util: Build iov_buf library only when building samba

[Michael Adam]

On 2015-02-26 at 10:51 +0100, Volker Lendecke wrote:
> On Thu, Feb 26, 2015 at 10:28:32PM +1300, Andrew Bartlett wrote:
> > I think this particular issue is 'not a bug' in Samba.  I do draw the
> > line at not breaking packaging scripts.  The reason I say that is these
> > tend to assert on the exact form of the build product, yet we can, do
> > and will continue to re-organise our internal libraries, and so I think
> > packaging just needs to cope reactively. 
> 
> The concept of internal library just does not exist anymore.  People
> use and depend on the exact structure of the stuff that we declare as
> internal, there is nothing that can prevent them from doing so. If we
> want to be nice to people, we need a different way of telling them about
> areas where we want to take the liberty to change things without a proper
> release management and taking care of proper compatibility layers. Saying
> "private_library=True" is not sufficient anymore.

It should be. Why are you not a little more self-assured and
tell those external consumers that they have done something
wrong instead of saying 'Uh, there is an external user? Apparently
I am not allowed to change it any more...' At least that would
feel more right to me. The external consumer can always come
and ask if we can publish a subsystem/library and we can
consider.

> Tough problem, but as it how happened the second time in quick succession
> we need a more general solution. If we can't solve this, we are really
> stuck with what we have now and need to just give up on refactoring.

Well. I think the case at hand is different. It is just internal.
And the fix for that was not reverting a change but making a
small change to the build script. That should not have stepped
on your toes so badly.

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/20150226/c28f19da/attachment.pgp>