[SSSD] [PATCHES] Split off helper libraries into their own packages

Stephen Gallagher sgallagh at redhat.com
Tue Feb 2 12:04:55 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/01/2010 07:11 PM, Dmitri Pal wrote:
> Stephen Gallagher wrote:
>> Patches 0001-0003: License and package libpath_utils
>>
> 01: In the header should the COPYING.lesser be COPYING.LESSER? Otherwise Ok.

I will correct that.

> 02: Ok
> 03: I can' review this file I do not know the RPM syntax yet.
> 
>> Patches 0004-0007: License and package libcollection. (Patch 0005 fixes
>> an incorrect #include in collection.h)
>>
> 04: Seems Ok, but now I am confused. I thought we had both licenses on
> the level above in "common", is this not enough? I thought we
> investigated that this is enough. What has changed. Why we put them in
> all places?

After more consideration, I realized that it is necessary to have the
licenses in the root of any location where we run "configure", because
it is possible to generate a tarball at that time. If we were to create
a libcollection-only tarball, it needs to have its license included as well.

> 05: Is it just for cleanness of the interface? Seems ok if it compiles.

It's not for "cleanness of the interface". The trace.h header is not an
installed header. Requiring it in a public header means that no code
that builds against libcollection will compile.

> 06: Seems Ok but I am not an expert. Second pair of eyes would not be
> redundant. Should the -version-info 1:0:0 match the versions in the
> configure.ac?

- -version-info refers to the API version, not the program version. The
three numbers mean:
current
    The most recent interface number that this library implements.
revision
    The implementation number of the current interface.
age
    The difference between the newest and oldest interfaces that this
library implements. In other words, the library implements all the
interface numbers in the range from number current - age to current.

If two libraries have identical current and age numbers, then the
dynamic linker chooses the library with the greater revision number.

> 07: I can' review this file I do not know the RPM syntax yet.
> 
> 
>> Patch 0008-0011: License and package libini_config. (Patch 0009 fixes an
>> array index mistake that was throwing a compiler warning and would have
>> been a potential memory-corruption bug.)
>>
> 08: same as 04.
> 09: good catch, full ack
> 10: same as 06
> 11: same as 07
> 
>> Patch 0012-0014: License and package libref_array
> 
> 12: same as 04
> 13: Seems Ok but I am not an expert. Second pair of eyes would not be
> redundant. Should the -version-info 1:0:0 match the versions in the
> configure.ac?
> 14: same as 07
> 
> 
> Bottom line.
> I do not see major issues with what I understand.
> I have a dirty tree so I did not apply the patches.
> If the patches apply, the version should not match (I suspect it should
> not because something tells me that version-info might define the
> version of the shared library interface) and someone checks the RPM
> patches I think there will be a joint ack.
>>
>>
>> These are all very simple patches, there are just a bunch of them :) It
>> should be an easy review.
>>
> 
> -------------------------
> 
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel
> 
> 


- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAktoFOMACgkQeiVVYja6o6Po/gCdEEEh6v8kDd5AeJI+sKcm+brf
lEUAnRp/zDUwLN5weF7sW2PMeBiPGtGf
=druE
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list