Sven Neumann writes:

While GIMP is approaching the 2.0 release, the libgimp* APIs are stabilizing and it's about time to update plug-ins so they will work with GIMP-2.0

as gimp packager in mandrake linux distribution, there's one thing that has always annoy me with the way gimp is released upstream.

a library soname should be .so.

the major number should be increased when abi or api is broken/altered (eg: libpng-1.0.x was libpng.so.2 whereas libpng-1.2.4 is libpng.so.3).

ie the library major is not related to the library version number. major is not increased on version bump but on api and/or abi change (eg: libgal keep increasing its major because of this and gal-0.24 provide libgal.so.23)

this enable to have different versions of the same libray installed at the same moment because different programs need different libraries version (eg: libgk+-1.2 and libgtk+2.0)

as gimp is concerned:

- in the 1.0.x days, its library major was 1.

- then in the 1.1.x days, the soname switched from libgimp.so.1 to libgimp-1.1.so.25
aka gimp stoped to follow std major library numbering

- in the 1.2.x, it's now libgimp-1.2.so.0

- in the 1.3.x, gimp-1.3.23 library soname is libgimp-1.3.so.23

that is gimp does not anymore follow std major library numbering: - its library major is set to its minor version. - the soname contains the first part of the version number

i would like next releases of gimp to follow std library major numbering:
- switch back to libgimp.so.23
- increase library major only on API or ABI change (thus libgimpui major may differ from libgimp ...) - do not ever reset major to 0 when gimp-2.0.x is released

this would enable: - saner packaging of gimp
- distro packagers would know when they've to rebuild packages that depends of gimp because major has been bumper thus meaning that: o either packages should be linked against latest lib because of new abi
o or package should be patched for new api

thanks :-)

Sven Neumann writes:

We do follow the standard library version numbering. The problem is that either you did not understand it or didn't look close enough. Let's have a look at configure.in:

standard libray versioning scheme is to set soname to lib. (library being named lib.. on
filesystem)

you confuse library version number and library major. you do not have to put version number in soname.

some examples: --------------
arts1-1.1.94 major is 2 for libkmedia aspell-0.50.3 major is 15
freetype-2.1.4 major is 6
gal-0.24 major is 23
gcc-3.3.1 major are 1 for libgcc and 5 for libstdc++ gmp-4.1.2 major is 3
gnome-libs-1.4.2 major are 32 for libgnome and 1 for gtkxmhtml gnomeprint-0.37 major is 15
gnomespeech-0.2.8 major is 6
gtkspell-2.0.3 major is 0
kde3.2 majors are 0 for kdegraphics, 1 for kdeaddons, kdeadmins, kdetoys, kdesdk, kdeedu, kdeutils and kdemultimedia, 2 for kdenetwork, kdepim, 3 for kdedevelop, 4 for kdebase, ...
krb5 majors are 2 for krb4 and 3 for krb5 libmpeg-1.5 major is 3
mozilla-1.5 major is 4 libnspr and 3 for libnss ntfsprogs-1.7.1 major is 4
png lib 1.2.5 major is 3
raw1394-0.9.0 major is 5
vorbis-1.0 majors are 0 for main vorbis lib, 2 for vorbisenc, 3 for vorbisfile (...)

The libraries have the binary version in their names because they are different. libgimp-1.2 and libgimp-2.0 are different libraries and by no means compatible.

the same way newers version of libal are binary incompatible with previous ones because of api additions, changes, ... (or any toolkit because of new/obsolete widgets).

the same is very true for every other project out that properly bump its library major instead of hardcoding the library version name in its soname (which is dumb when a new version is binary and source compatible with the previous ones - at least gimp does not hardcode its minor version number in its soname)

if the a branch of a library is not compatible with the previous one, maintainer only has to bump its major. nothing more.

They are supposed to coexist so they need the binary version in the library name.

different versions of the same library coexists because they've different majors.

this is how different versions of gal coexists

The library version is then created from the version information as given above. During a development cycle, each release is incompatible to the previous, so interface age and binary age are always set to 0. When 2.0.0 is out, we will apply the rules as given above. This is certainly a very much standardized way of handling library versions and I can you give you a very long list of projects that do it this way.

and i can also give you a very long list of projects that do it the other way.

Sven Neumann writes:

standard libray versioning scheme is to set soname to lib. (library being named lib..
on filesystem)

Don't get confused by the numbers, libgimp-2.0 is the library name we've choosen. There is nothing wrong with that. It's just a name.

if the a branch of a library is not compatible with the previous one, maintainer only has to bump its major. nothing more.

That's exactly what we are doing. Nothing more. Please have a look at the versioning scheme I pointed you at. It does exactly what you are suggesting.

but it makes packaging harder for distros.

both debian and mandrake (and even redhat now due to gtk+-1.2 to gtk+-2.x transition) use versionned packages for library (eg one can install libfoo2-1.0.1 and libfoo3-1.1.9 at the same time)

this system works great for quite a number of libraries.

but for libraries that include their version number into their soname, this makes packaging harder when one want to still be able to keep several versions of the same library.

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.

eg: libgimp is named libgimp1.3_22-1.3.22-1mdk.i586.rpm on mandrake and libgimp1.3_1.3.22-3_i386.deb on debian [1].

sadly, this is less readable.

this also pressure packages managers by increasing the ammount of requires and provides (because libfoo provides libfoo = bar).

what's more development packages (aka headers, build infrastructure such pkgconfig files) conflicts (different names due to version number being included in package name).
this can be workarounded by not including the minor version number in devel package name.

but there's also the problem that currently we also have to rebuild dependant packages on each gimp release because major bumped on each release (since lib major equals version number's minor) even if there really wasn't any api change.

i usually advocate the "let bump the major lib" on api/abi change because it enable to track common problems:

- undetected symbols mismatch that requires relinking because of abi change when one lib as the same soname but one package requires the foo version whereas another one requires bar version (both using the same major) resulting in one of them being silently broken,

- undetected need for rebuild and patching on api/abi change,

- uneeded breakage in third party programs (though i personnaly do not really care about it by myself, i do understand that it can annoy non free software vendors)

i agree that you way works too and i agree the packaging issues may not be strong enough so that you alter gimp library versionning system.

note that you approach results in having several libgimp1.3.XYZ libs installed at the same time when one update whereas there were no real api change (easily "fixable" of course but ...).

[1] i provide gimp1.3 in contribs because so much people complain to me about font issues with gimp-1.2.x

On Tue, Dec 02, 2003 at 04:09:04PM +0000, Thierry Vignaud wrote:

Sven Neumann writes:

standard libray versioning scheme is to set soname to lib. (library being named lib..
on filesystem)

Don't get confused by the numbers, libgimp-2.0 is the library name we've choosen. There is nothing wrong with that. It's just a name.

if the a branch of a library is not compatible with the previous one, maintainer only has to bump its major. nothing more.

That's exactly what we are doing. Nothing more. Please have a look at the versioning scheme I pointed you at. It does exactly what you are suggesting.

but it makes packaging harder for distros.

both debian and mandrake (and even redhat now due to gtk+-1.2 to gtk+-2.x transition) use versionned packages for library (eg one can install libfoo2-1.0.1 and libfoo3-1.1.9 at the same time)

this system works great for quite a number of libraries.

but for libraries that include their version number into their soname, this makes packaging harder when one want to still be able to keep several versions of the same library.

This is what GTK+ does. libgtk-1.2.so.0 and libgtk-x11-2.0.so.0. GIMP does the same thing as GTK+.

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).

There are no ABI guarantees for 1.3.x since it's a development series. As Sven said, we do break it. It is a development series, so you just have to deal. When it hits 2.0, that's a stable series, and the ABI will be maintained.

Note that GTK+ 1.3.x bumped the major so number at every release too.

-Yosh

On Tue, Dec 02, 2003 at 06:24:49PM +0100, Sven Neumann wrote:

i usually advocate the "let bump the major lib" on api/abi change because it enable to track common problems:

myself on this), we do exactly this. During a development cycle, each and every release is incompatible with the former release, that's why

That's, of course, factually wrong. Real incompatibilities have been very rare in practise. What's true is that often a newer version provides features not found in older gimps and vice versa. However, it still did support the old api, which is IMHO the point.

We use the same versioning scheme as almost all of the libaries we depend on. That alone is a strong argument to stick with it.

(Philosophically, I always had a problem with agruments of the form: the others do it, so it must be right. libtool does a lot of things wrong, e.g. forcing -fPIC and other things for no good reason. Just because many packages use libtool, for example, does not magically make it correct).

I doubt that you can find a release in the 1.3 cycle that is API and ABI compatible with another release from the 1.3 cycle.

Very often during the early 1.3 releases I simply re-linked gimp-perl. For many plug-ins, I also just symlinked the old library name to the new library binary, and only once had a problem with that. That's why I wrote "factually wrong".

admit that we don't go thru the hassle of checking this for each release but simply follow the policy of assuming that the API has changed. But I am pretty sure that it did indeed change for every or at least almost every 1.3 release.

Still, you don't bump the major library number, which is the standard and historic way to do that, as you have special support from your dynamic linker for that. Changing the name works, too, but I never understood why the established and working scheme is not used by the g* community. yes, many packages use it, but the majority of packages out there does not, especially packages not within the gnome (and to a lesser extent gnu) communities.

On Tue, Dec 02, 2003 at 01:25:24PM -0800, Manish Singh 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.

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..."

Note that GTK+ 1.3.x bumped the major so number at every release too.

Again, "others do it", is not a sound argument...

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 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

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. ;)

Now that's an extremely good argument :)

On Tue, Dec 02, 2003 at 04:09:04PM +0000, Thierry Vignaud wrote:

[1] i provide gimp1.3 in contribs because so much people complain to me about font issues with gimp-1.2.x

you could include the gimp-freetype plug-in (http://freetype.gimp.org) get the one with a 2 in it for gimp-1.2. this plug-in takes care of all the problems i had with fonts in gimp-1.2, debian woody, sarge and lately sid.

carol

Carol Spears writes:

[1] i provide gimp1.3 in contribs because so much people complain to me about font issues with gimp-1.2.x

you could include the gimp-freetype plug-in (http://freetype.gimp.org) get the one with a 2 in it for gimp-1.2. this plug-in takes care of all the problems i had with fonts in gimp-1.2, debian woody, sarge and lately sid.

gimp2-freetype is already packaged in mandrake contribs since Sun Aug 10 2003 :-)

i didn't know that it was for gimp-1.2.x branch.

thanks for the information

Sven Neumann writes:

gimp2-freetype is already packaged in mandrake contribs since Sun Aug 10 2003 :-)

i didn't know that it was for gimp-1.2.x branch.

Well, what exactly did you package?

i package gimp, gimp-data and gimp1_3.

a contributor packaged gimp-freetype-0.4.tar.bz2 as gimp2-freetype which indeed is for gimp2.

Sven Neumann writes:

Hi,

Thierry Vignaud writes:

i package gimp, gimp-data and gimp1_3.

a contributor packaged gimp-freetype-0.4.tar.bz2 as gimp2-freetype which indeed is for gimp2.

gimp-freetype-0.4 has never been officially released. I suspect that the package was built from CVS then.

yes, the package version number explictely said this: gimp2-freetype-0.4-0.20030810.2mdk

If it was built from CVS in August, then it won't work with the latest 1.3 releases. For that reason, I kindly ask you to remove this package. If you want to, you can build a new one based on the current state in CVS, but please don't name it gimp2-freetype until the 2.0 API is completely frozen and it can be sure that the package will indeed work with GIMP-2.0.

we do not remove packages just because they're build from cvs. being build from cvs rather than an official release does not imply less stability (there're packages for which this is false ...). also some projects do not do official releases for quite a long time despite being stable and usual (eg perl-gtk2 binding which was more usuable and robust than old perl-gtk1 binding).

anyway it need to be rebuild for current gimp1.3.

abel, götz ?

Sven Neumann writes:

we do not remove packages just because they're build from cvs. being build from cvs rather than an official release does not imply less stability (there're packages for which this is false ...).

I didn't say this. What I said is that the package definitely doesn't work with the latest GIMP-1.3 releases and that rebuilding the package will not fix this. You will need to use a recent CVS checkout.

and i never said the reverse

I also kindly asked you to consider changing the name of the package.

i considered it. i gived my opinion. i wille left the final words on initial packagers but i do think that this name nicely show that it's not for gimp-1.2.x.

here's why:

1) package coexistance: =======================

since i'll package the 0.2.x version for the gimp-1.2.x branch, the cvs snapthot for gimp1.3.x will either be named gimp1.3-0.4 or gimp2-0.4.

since mdk9.2 came with a gimp2-freetype package with hard dependancie on libgimp1.3_20-1.3.20-1mdk, i do not think it's a problem that we've now a new cvs snapshot packaged as gimp2-freetype that require that requires libgimp1.3_23-1.3.23.

2) naming coherency: ====================

of course, we can rename it now. but as:

- mdk9.2 contribs came with gimp2-freetype

- renaming current package would only affect cooker which is just a moving development distro that is not for end users but for cooker developers

- gimp-devel stated that gimp-2.x will come soon, so mdk10.0 would provide gimp2 and gimp2-freetype

i do not think it's wise to rename this package only in a package repositery that is not used by end users.

that would force us to use an epoch tag in that package for no good reason since eventualle the package name would be the same in two consequent mandrake linux releases.

we unofficially plan to release mdk10.0 in february.

we'll either keep gimp-1.2.x in main and gimp1.3.x in contribs or we'll provide both gimp-1.2.x and gimp-2.0.x in main (and then in next release, gimp-1.2.x would go in contribs or just vanish)

after reading gimp-devel, i think the odds're high that gimp-1.3.x will at leat be some gimp-2 pre-release at that time, so i really think that this renaming is uneeded (thus preventing useless moves in spec files cvs module due to package renaming).