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

Jakub Hrozek jhrozek at redhat.com
Mon Apr 29 15:23:48 UTC 2013


On Mon, Apr 29, 2013 at 08:13:21AM -0400, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 04/29/2013 06:46 AM, Michal Židek wrote:
> > On 04/25/2013 05:18 PM, Stephen Gallagher wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >> 
> >> On 04/24/2013 06:11 PM, Simo Sorce wrote:
> >>> On Wed, 2013-04-24 at 20:55 +0200, Sumit Bose wrote:
> >>>> On Wed, Apr 24, 2013 at 02:22:42PM -0400, Stephen Gallagher 
> >>>> wrote:
> >>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>>>> 
> >>>>> On Wed 24 Apr 2013 02:05:55 PM EDT, Michal Židek wrote:
> >>>>>> New version of the patch is attached.
> >>>>>> 
> >>>>>> Changes from previous iteration: - version-info set to
> >>>>>> 0:2:0 - init function remains backward compatible, but it
> >>>>>> sets default oadptions needed for range calculation. Non
> >>>>>> default values can be set via ded setters. -
> >>>>>> sss_idmap_opts moved to private header
> >>>>> 
> >>>>> This is still a backwards-incompatible break. If we were 
> >>>>> presenting a data structure in a public header and no
> >>>>> longer are, it's an ABI break. Is there any way to avoid
> >>>>> this?
> >>>> 
> >>>> sss_idmap_opts is introduced with this patch, it was in the 
> >>>> public header in the first version and Michal moved it into
> >>>> the private one in the new version.
> >>> 
> >>> I think Steven was referring to struct sdap_idmap_slice 
> >>> disappearing from src/providers/ldap/sdap_idmap.h maybe ?
> >>> 
> >> 
> >> Actually, I hadn't looked at the patch. I saw that he had moved
> >> a structure from a public to a private header and didn't realize
> >> it was a newly-added structure.
> >> 
> >> 
> >> One nack: the version-info string needs to be 1:0:1 according to 
> >> http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
> >>
> >>
> >>
> >> 
> This is because you have added the getters and setters to the public
> >> interface, which means that all of steps 3, 4 and 5 in that
> >> guideline must be followed, which results in a value of 1:0:1 for
> >> version-info. Note: this arrangement does NOT result in a SOname
> >> bump, because the "age" is equal to the "current" (Which
> >> effectively means that we're saying that this interface is a
> >> proper superset of all interfaces that have preceded it).
> > 
> > Thanks a lot for the explanation Stephen. I was actually following
> > the same guide, but I thought that only one rule is applied each
> > time version-info is changed, which did not make much sense in
> > some situations. Now it finally makes sense to me.
> > 
> > New patch is attached.
> > 
> 
> Ack!

Pushed to master.



More information about the sssd-devel mailing list