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
> 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
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. ;)
Gimp-developer mailing list