1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
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>
|
