[SSSD] [PATCH 1/2] libsss_idmap: function to calculate range

Simo Sorce simo at redhat.com
Tue Apr 23 17:50:35 UTC 2013


On Tue, 2013-04-23 at 11:26 -0400, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 04/23/2013 10:37 AM, Michal Židek wrote:
> > Also one more question. How should I amend the -version-info value
> > for libsss_idmap in Makefile.am? Currently it is 0:1:0. Should it
> > be 1:0:0 now?
> > 
> 
> With your patch as written, yes you will need to change it to 1:0:0
> (because you modified a public function and two public data
> structures). This will effect a soname bump and require that consumers
> rebuild against this.
> 
> It also means that you will need to make an announcement on
> Fedora-devel about the soname bump and make sure to coordinate the
> update so that all projects relying on this library rebuild together.
> Please do not do this in Fedora 18.
> 
> A quick repoquery suggests that only SSSD and FreeIPA are consuming
> this library in Fedora (as expected), but it's not impossible that
> there are third-party tools out there consuming the library for their
> own purposes, so please be sure to announce.
> 
> Unfortunately, I don't really see any way of avoiding the bump.

Except, do we really need to make this incompatible change ?

If I read the patch correctly idmap_opts are only needed in
sss_idmap_calculate_range() which is a new function, so we could avoid
passing idmap_opts to ss_idmap_init and instead pass the struct directly
to sss_idmap_calculate_range().

The other change is slice_num stored in the range, but do we really need
to store it ? Or could we implement overrides as options on idmap_opts ?
After all I do not really see why a "range" would include a slice
number.

I think we can make a change that only adds functionality w/o changing
existing functions.

Another question I have is, why do we have getters if the idmap_opts
structure is public ?

I would either make it opaque and have a creation function or not have
setters.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list