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 <yosh@xxxxxxxx> 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
