On Tue, Dec 02, 2003 at 11:30:26PM +0100, Marc A. Lehmann wrote:
On Tue, Dec 02, 2003 at 01:25:24PM -0800, Manish Singh [EMAIL PROTECTED] wrote:
since the major is not anymore unique (eg gimp-2.0.23 will provide
libgimp-2.0.so.23 with the same major as libgimp-1.3.so.23 from
gimp-1.3.23), we've to include version number into package name too.
No, you misunderstand. GIMP 2.0.0 will provide libgimp-2.0.so.0.0.0. GIMP
2.0.23 will provide libgimp-2.0.so.0.0.23. ABI will be maintained for the
the 2.0.x series (and possibly the 2.x series, if we decide to do that).
hmm, I don't think both of you are talking about the same thing, as I
think both of you are right, but you are talking past each other.
No, I think I answered the question, since the original poster brought up
a number of libraries that do the same foo-X.Y.so.Z as doing the right
thing.
The point is, according to custom packaging rules:
libgimp-1.3.so.23 = libgimp23
libgimp-2.0.so.0.0.23 = libgimp23
(debian, mandrake.. linux in general). Gimp uses a major of 0 all the
time, and thus it's useless to distinguish between major numbers, you need
to include the version number (that is, not the library version number
but the version string encoded in the _name_, or stem), and, while this
is correct, it's a hassle, somewhat more difficult to use etc.
Of course, it's perfectly doable. the question is what the benefits are, I
mean, you usually get some benefits while sacrificing others.
And since the normal way to manage libraries is both established and does
solve the problems, it's hard to explain why a second, incompatible (but
of course perfectly working) scheme is required or useful.
I simply suspect that this has crept in because it's the only portable way
to get it right (e.g. on windows, which doesn't have a de-factor workign
dll versioning system, although dlls do come with versions).
So, the gimp scheme works anywhere where you can have long enough
filenames (== everywhere), while the usual ELF-way only works on
platforms where encoding the major at the end is established practise.
As such, the benefit might be less hassle and less platform specific
code. That is enough to justify it, to me, but if it's the case one
should acknowledge it and simply tell people: if you want to fixed, write
the patch and get it into the neccessary packages...
OK, the main reason is that while the so major number solves things for
running binaries compiled against different library versions, it doesn't
address *building* binaries against different library versions in the
same prefix.
So if there was a libgimp.so.1 for 1.x and libgimp.so.2 for 2.x, the
compile time linker only looks at a libgimp.so, which can be symlinked
to one or the other, but not both at the same time. So if a user wants
both a build environment for 1.2 and 2.0 installed, he'll have to jump
through extra hoops to get it to work. Hence the different sonames.
Another reason, which admittedly solves what can be termed as an annoyance,
is that many users simply don't get that the so version numbers don't
necessarily match the actual version of the software. Look at the people
who think they have Freetype version 6 just because the so major num is 6
(current version is 2.1.7). This means more round trips and confusion
when dealing with bugs.
So what are the real downsides here? pkg-config deals with the library
names, so that isn't really an issue. Packagers have to put version
numbers in their package names, but that enables a useful feature of
parallel installation, so it's good to have. It causes *less* confusion
with users since libgimp-2.0.so.0 is obviously a gimp 2.0 library,
as opposed to libgimp.so.47.
Note that GTK+ 1.3.x bumped the major so number at every release too.
Again, others do it, is not a sound argument...
Yeah, but the original poster implied in his mail that GTK+ was doing
the right thing by him. I was pointing out the GTK+ does the same thing
as GIMP, so if he thinks it's right, then GIMP is right too. ;)
-Yosh
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
