On Tue, 2013-04-23 at 11:26 -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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
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
I think we can make a change that only adds functionality w/o changing
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
Simo Sorce * Red Hat, Inc * New York