Re: [Gimp-developer] Re: [Gimp-announce] ANNOUNCE: gimp-plugin-template 1.3.2
Hi, Thierry Vignaud [EMAIL PROTECTED] 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? gimp2-freetype sounds like it should be working with gimp2 which isn't even released yet, so the package name is certainly bad choosen. Is this built from CVS or from one of the released tarballs? There have been two releases so far: - gimp-freetype-0.2 is for GIMP-1.2 - gimp-freetype-0.3 is for an earlier GIMP-1.3 API and won't work with latest GIMP-1.3 releases I will probably do another gimp-freetype release for GIMP-2.0. However the usefulness of gimp-freetype for GIMP-2.0 is questionable since the text tool has most of its features already (and a few more). Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-announce] ANNOUNCE: gimp-plugin-template 1.3.2
Sven Neumann [EMAIL PROTECTED] 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. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-announce] ANNOUNCE: gimp-plugin-template 1.3.2
On Tue, Dec 02, 2003 at 04:09:04PM +, 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-announce] ANNOUNCE: gimp-plugin-template 1.3.2
Carol Spears [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-announce] ANNOUNCE: gimp-plugin-template 1.3.2
Sven Neumann [EMAIL PROTECTED] 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 libname.major (library being named libname.major.minor 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. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-announce] ANNOUNCE: gimp-plugin-template 1.3.2
Hi, Thierry Vignaud [EMAIL PROTECTED] writes: 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: As I said already (and this is certainly the last time I am repeating myself on this), we do exactly this. During a development cycle, each and every release is incompatible with the former release, that's why interface_age and binary_age are always reset to 0. 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. 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. 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 ...). 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. I have to 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. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-announce] ANNOUNCE: gimp-plugin-template 1.3.2
Hi, Thierry Vignaud [EMAIL PROTECTED] writes: standard libray versioning scheme is to set soname to libname.major (library being named libname.major.minor 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. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-announce] ANNOUNCE: gimp-plugin-template 1.3.2
On Tue, Dec 02, 2003 at 04:09:04PM +, Thierry Vignaud wrote: Sven Neumann [EMAIL PROTECTED] writes: standard libray versioning scheme is to set soname to libname.major (library being named libname.major.minor 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-announce] ANNOUNCE: gimp-plugin-template 1.3.2
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
[Gimp-developer] Re: [Gimp-announce] ANNOUNCE: gimp-plugin-template 1.3.2
Sven Neumann [EMAIL PROTECTED] 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 libname.so.major 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 :-) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-announce] ANNOUNCE: gimp-plugin-template 1.3.2
Hi, 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: # # Making releases: # GIMP_MICRO_VERSION += 1; # GIMP_INTERFACE_AGE += 1; # GIMP_BINARY_AGE += 1; # if any functions have been added, set GIMP_INTERFACE_AGE to 0. # if backwards compatibility has been broken, # set GIMP_BINARY_AGE and GIMP_INTERFACE_AGE to 0. # GIMP_MAJOR_VERSION=1 GIMP_MINOR_VERSION=3 GIMP_MICRO_VERSION=23 GIMP_INTERFACE_AGE=0 GIMP_BINARY_AGE=0 GIMP_VERSION=$GIMP_MAJOR_VERSION.$GIMP_MINOR_VERSION.$GIMP_MICRO_VERSION 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. They are supposed to coexist so they need the binary version in the library name. 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. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
