diff options
author | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
---|---|---|
committer | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
commit | 1be510f9529cb082f802408b472a77d074b394c0 (patch) | |
tree | b175f9d5fcb107576dabc768e7bd04d4a3e491a0 /zarb-ml/mageia-dev/2012-December/020439.html | |
parent | fa5098cf210b23ab4f419913e28af7b1b07dafb2 (diff) | |
download | archives-master.tar archives-master.tar.gz archives-master.tar.bz2 archives-master.tar.xz archives-master.zip |
Diffstat (limited to 'zarb-ml/mageia-dev/2012-December/020439.html')
-rw-r--r-- | zarb-ml/mageia-dev/2012-December/020439.html | 147 |
1 files changed, 147 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-December/020439.html b/zarb-ml/mageia-dev/2012-December/020439.html new file mode 100644 index 000000000..3611940d6 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-December/020439.html @@ -0,0 +1,147 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Utter frustration + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Utter%20frustration&In-Reply-To=%3C50B965C5.3010200%40roadrunner.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="020446.html"> + <LINK REL="Next" HREF="020440.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Utter frustration</H1> + <B>Frank Griffin</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Utter%20frustration&In-Reply-To=%3C50B965C5.3010200%40roadrunner.com%3E" + TITLE="[Mageia-dev] Utter frustration">ftg at roadrunner.com + </A><BR> + <I>Sat Dec 1 03:04:53 CET 2012</I> + <P><UL> + <LI>Previous message: <A HREF="020446.html">[Mageia-dev] pushing pcre-8.32-2 manually +</A></li> + <LI>Next message: <A HREF="020440.html">[Mageia-dev] [RPM Groups] RPM group change before Beta 1 (fixed title) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#20439">[ date ]</a> + <a href="thread.html#20439">[ thread ]</a> + <a href="subject.html#20439">[ subject ]</a> + <a href="author.html#20439">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Op vrijdag 30 november 2012 12:59:25 schreef Anne Wilson: +>><i> On 30/11/12 12:26, Frank Griffin wrote: +</I>>>><i> On 11/30/2012 07:13 AM, Anne Wilson wrote: +</I>>>>><i> Before doing all that, can you explain the significance of the +</I>>>>><i> suffixes here? +</I>>>>><i> +</I>>>>><i> ls /usr/lib/ | grep powerdevil +</I>>>>><i> libpowerdevilconfigcommonprivate.so.4@ +</I>>>>><i> libpowerdevilconfigcommonprivate.so.4.10.0* +</I>>>>><i> libpowerdevilcore.so.0@ libpowerdevilcore.so.0.1.0* +</I>>>>><i> libpowerdevilui.so.4@ libpowerdevilui.so.4.10.0* +</I>>>><i> Library naming conventions use several, actual version, e. g. +</I>>>><i> 4.10.0, major version, e. g. 4, and a generic name, e. g. +</I>>>><i> libxxx.so. The last two are usually symlinked to the first. +</I>>>><i> +</I>>>><i> The major version usually signals an ABI difference or some other +</I>>>><i> major difference, e. g. new function, from the previous version. +</I>>>><i> The actual version changes whenever any change is made. Developers +</I>>>><i> use the major version if their code is dependent on that major +</I>>>><i> version, but just use the generic name if any version will do. +</I>>>><i> +</I>>>><i> In this way, the majority of packages using the library just ask +</I>>>><i> for libxxx.so, and don't have to be rebuilt or have their makefiles +</I>>>><i> or spec modified when the library changes. A few packages, which +</I>>>><i> are dependent on a specific version, ask for libxxx.so.N (or +</I>>>><i> higher), and these have to be changed when the major version they +</I>>>><i> require is released. A very very few packages are dependent on the +</I>>>><i> actual version, and these may have to change more often. +</I>>><i> I assume the starred ones are actually in use - what's the +</I>>><i> significance of '@'? I'm not sure I've really understood this. +</I>>><i> +</I>OK, say libXXX provides functions funcA, funcB, and funcC. The library +developer releases version 1.0.0, and the package installs +libXXX.so.1.0.0 and symlinks libXXX.so.1.0, libXXX.so.1.0, and libXXX.so +to this. + +Now, the library developer fixes some minor bugs. They don't involve +any changes to the binary interface (ABI), e. g. they don't change the +datatypes of any of the parameters to the three functions, and they +don't change the number of parameters to any of them. So any +application that used version 1.0.0 should work with the new version. +The developer calls this version 1.0.1, and when the libXXX package +installs, it adds libXXX.so.1.0.1, and changes the libXXX.so.1 and +libXXX.so symlinks to point to that. Applications which used 1.0.0 by +asking for libXXX.so or libXXX.so.1 don't see any difference. If an +application specifically asked for libXXX.so.1.0, it gets the older +version (provided you didn't unistall it). Same goes for an application +that specifically asks for libXXX.1.0.0. + +Now, suppose the library developer adds funcD to the library, and +doesn't change the ABI (Application Binary Interface) of A/B/C. He +calls the new package 1.1.0, and when it installs, it installs +libXXX.so.1.1.0, adds a libXXX.so.1.1 symlink to it, and changes the +linXXX.so symlink accordingly. Applications that used 1.0.0 or 1.0.1 +could only use funcA/B/C, and will work exactly as they always did with +the new version. But a new application that uses funcD won't work with +the older versions, so its package has to say that it requires 1.1.0 or +later. + +Now the library developer finds a serious day-zero bug in funcA. Maybe +one of the parameters was originally an int when it should have been a +time_t, and the library doesn't work with newer system libraries because +time_t has changed from an int to an int64. This means that the ABI +changes. Applications compiled to use the older libraries won't work +with the newer versions. Applications written to use the newer version +won't work with the older versions. + +So the library developer bumps the major version and releases 2.0.0, +along with an advisory that any applications with dependencies on the +ABI changes from 1.x.x. -> 2.0.0 must either be modified to use the +newer ABI (in which case they can continue to use libXXX.so and +requiring >=libXXX.so.2) or must have their spec file modified to +require =libXXX.so.1 or <=libXXX.so.1.1. + +Any app that just asks for libXXX.so has to be modified to use the new +funcA ABI whether it uses funcD or not. Any app that uses libXXX.so and +uses funcD and the original ABI for funcA has to be changed to use +libXXX.so.1.1 and require <=1.1 or else be changed to use the the new ABI. + +As time goes on, either the source code or the makefiles/specfiles for +old apps have to be changed in one way or the other. But the intent is +that as many old apps as possible can use libXXX.so until circumstances +make that impossible. At that point. the makefile/specfile has to +change in a minor way, if you're willing to have multiple versions of +libXXX installed. Or, if the app is under active development, the +developer can choose to update the source to conform to the newer ABI +and update the makefile/specfile to require at least the version that +supports that ABI. +</PRE> + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="020446.html">[Mageia-dev] pushing pcre-8.32-2 manually +</A></li> + <LI>Next message: <A HREF="020440.html">[Mageia-dev] [RPM Groups] RPM group change before Beta 1 (fixed title) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#20439">[ date ]</a> + <a href="thread.html#20439">[ thread ]</a> + <a href="subject.html#20439">[ subject ]</a> + <a href="author.html#20439">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |