On 2014-10-21 18:11, Daniel P. Berrange wrote:
> On Tue, Oct 21, 2014 at 03:59:46PM +0100, David Howells wrote:
>> I assumed that adding them to KEYUTILS_1.4 would be okay because nothing
>> would've tried to use them previously because they didn't exist in any
>> version.
>
> One thing to bear in mind with symbol versioning is that it also interacts
> with RPM versioning. ie, if an application links to a symbol foo@MYLIB_X.Y
> then the RPM will automatically get a "Requires: mylib.so(MYLIB_X.Y)"
> added to it.
>
> This ensures that when you install the application, it pulls in a version
> of the library that is new enough to have all the symbols the application
> needs.
>
> Note that RPM only depends on the version, not the full symbol name. So
> by adding new symbols to the existing KEYUTILS_1.4 version section, no new
> RPM dependancies will be introduced. So an RPM install of an application
> that uses the new symbols, will still be (mistakenly) satisfied by the
> an old version of the library that lacks the symbols.
Within Debian, library source packages can make use of a special
versioning system which is used by other packages to calculate dependencies.
In this versioning system, every upstream symbol is mapped to the Debian
source package version in which this symbol was introduced into the
archive. For example, for the two symbols discussed above, we have
[...]
recursive_key_scan@KEYUTILS_1.4 1.5.2
recursive_session_key_scan@KEYUTILS_1.4 1.5.2
[...]
indicating that the two upstream symbols *@KEYUTILS_1.4 where first
introduced into Debian with package version 1.5.2 (apparently upstream
releases 1.5.0 and 1.5.1 were skipped). Consequently, packages built
against libkeyutils1 using those symbols will always depend on a Debian
package version of at least 1.5.2, despite them being marked as 1.4
upstream.
This allows for a much finer control of package dependency calculation
than the default we use. But, of course, this only applies when the
package maintainer actually decides to use this feature.
Just thought this might be something interesting to share.
Regards,
Christian
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
