What exactly makes tdb2 hard to package (ccan?)

[Jelmer Vernooij]

Am 09/04/12 08:59, schrieb Andrew Bartlett:
> On Thu, 2012-04-05 at 16:08 +1000, Andrew Bartlett wrote:
>> I've been told that the issues with bundled ccan libs are still causing
>> issues for distributors, so I've come up with a patch that I think
>> should help.  I'm doing this so we can separate these issues from any
>> other discussion around tdb2, as I think there are technical build
>> system issues we can address.
>>
>> These patches re-introduce the private library extension (-samba4, -ldb,
>> etc), but only for ccan.  This is on the basis (which I need to confirm)
>> that ccan has no static data that would cause an issue if duplicated.
>> Libraries with important static data like talloc are not renamed, and
>> will deliberately cause a library conflict as pre previous behaviour. 
>>
>> (BTW, Linux distributors should not bundle or distribute libreplace, but
>> instead depend on libbsd). 
>>
>> Please let me know if this helps.  The patches are attached, and in
>> https://git.samba.org/abartlet/samba.git/?p=abartlet/samba.git/.git;a=shortlog;h=refs/heads/less-ccan-pain
> In order to test this, I added a mode to autobuild that tries to build
> 'distribution style' Samba, that is based on 'system libraries' (in a
> private prefix in this case). 
>
> This should be in master soon, and should help us avoid regressions that
> have often hit distributors and OpenChange.  This patch uses tdb1, as
> this is what all distributors use, so it is an important use case to
> test.
>
> Then, I've then applied the attached patch to test building with tdb2,
> which I was expecting to fail.  It still passes, without any of the work
> I mention above.  
>
> So, I'm a little stumped.  Can someone describe the 'linux distribution
> packaging' failure mode here? (preferably in the form of a patch, so I
> can reliable test it)?
The main issue with tdb2 has been that it caused various kinds of
trouble - various missing symbol errors, concerns about duplicate symbols.

If I try to build Samba4 without --disable-tdb2 here, I get:

default/source3/libsmb/smb_share_modes_12.o: In function `smb_name_hash':
/home/jelmer/src/samba/bin/../source3/libsmb/smb_share_modes.c:320:
undefined reference to `hash_any'
collect2: ld gab 1 als Ende-Status zurück

(My ldb wasn't built against tdb2)

There have been various errors like this in the past; I've fixed a
couple, but presumably there are still some left. I suspect this is due
to the fact that waf thinks that ldb already includes ccan, so it no
longer has to build or link against it itself.

Even if I did have a ldb linked against tdb2 then this would be a
problem, since ccan doesn't have a stable ABI. So that symbol may not
actually exist (anymore).

Related to this (though not specific to packaging) is that ccan seems to
duplicate a fair bit of code that is already present elsewhere in Samba
(e.g. lib/util, lib/replace, test infrastructure). There is also a cost
to maintaining both tdb1 and tdb2 in the tree and supporting them both,
as we discussed on IRC.

Readding the suffix doesn't seem like a proper solution to me - it means
we still end up with three copies of ccan on each system with samba4 on
it. That doesn't seem to necessarily be better than building it as a
built-in library. This doesn't just apply to ccan btw, but also to
tdb_compat.

Cheers,

Jelmer


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120409/8016bf95/attachment.pgp>