ccan dependencies seems to break external projects
jelmer at samba.org
Tue Feb 21 16:08:00 MST 2012
On 02/21/2012 11:11 PM, Rusty Russell wrote:
> On Mon, 13 Feb 2012 08:04:14 -0500, Stephen Gallagher<sgallagh at redhat.com> wrote:
>> I don't think that encoding the version number in the library is a
>> sufficient answer since, as discussed earlier in this thread, it is
>> possible to build subsets of CCAN. This would presumably be the same
>> library version but would be notably missing some components and
>> therefore ABI-incompatible with an application linked against it.
> Hi Stephen,
> Thanks for bringing these issues up. It's important to figure
> out how to solve this not just for SAMBA, but for advice to other
> complex CCAN-using projects in future.
>> There really only seem like two options:
>> 1) CCAN needs to be modified so that we always build ALL components of
>> it into a shared library. Ideally we would do this upstream with CCAN
>> (and not privately in samba). Then we could have upstream release
>> tarballs with a defined version that samba should then link against. I'm
>> aware that Samba likes to have the ability to also build it in-tree, but
>> that's a secondary concern. This option allows distributions to package
>> a system library version of ccan (which is the preferred approach for
>> most distributions, since it allows easy upgrades to fix bugs and
>> security issues across all platforms).
> Making CCAN a versioned library is messy. Upstream, CCAN is simply a
> collection of code snippets with no set API, let alone ABI. That
> decision is up to individual module authors.
> This means SAMBA would be bumping the SO major version on every change
> we import, or make the fork permanent, which would be painful and make
> it harder to grab future CCAN modules.
Considering the fact that CCAN is mostly just a collection of code
snippets, I wonder if it really has to be a single public library in
Samba (and thus have some sort of ABI, if it is to be shared between ldb
I wonder if it might be more useful to simply keep a copy of (only) the
relevant files from ccan that we actually use in e.g. /lib/tdb2 and/or
/lib/util. As far as I know tdb2 and lib/util use different bits of
ccan, so there isn't actually a reason they need to share object files.
Is that correct?
It seems like the main cost of this would be (theoretical) code
duplication in the future, if other projects packaged by the
distributions start using the same modules from ccan too. I'm not sure
if we should really worry about that already. Can't we just deal with
that when we do get duplication in the archive?
More information about the samba-technical