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
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
> > 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 :) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ 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
Re: [Gimp-developer] Re: [Gimp-announce] ANNOUNCE: gimp-plugin-template 1.3.2
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. 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... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ 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 06:24:49PM +0100, Sven Neumann <[EMAIL PROTECTED]> 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. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ 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 > > > 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
