Re: [Gimp-developer] GNU/Linux vs. Linux
Roger Leigh [EMAIL PROTECTED] writes:
so should we speak of gnu-bsd-mpl-qpl-artistic/linux ?
or, as gpl softwares number is greater than gnu/fsf ones, should
we speak of gpl/linux ?
A distribution is much more than an operation system. If you just
look at the core components that make up the OS (I'm sure that there
will be plenty of contention regarding what these are ;-) then you
have a Linux kernel, and GNU tools.
looking at what the mandrake basesystem package requires as minimal
system :
util-linux (swapon, mount, ...), e2fsprogs, lilo, initscripts,
console-tools, chkconfig, SysVinit, bdflush, kernel, losetup,
net-tools, modutils, procps, psmisc, rpm, sysklogd, are all linux
specific tools.
only fileutils, grep, findutils, glibc're a gnu project part.
there's other small gnu packages requires (time, textutils,
sh-utils...) but they're less important than previous ones.
Most of the other programs are not essential--a bare bones system
will be mostly GNU stuff.
looking at the above, this is *very*, *very* mitigated
When talking about the kernel, `Linux' is appropriate, but when
talking about the /operating system/ as a whole `GNU/Linux' is more
accurate,
nope since gnu tools (yet an important part of the os) are'nt the
essential part.
neither is the bsd tools part. neither're gpl linux specific tools,
...
this is why i think linux and gnu/linux are equivalent (that is
they're equally mis-naming conventions) on a technical point.
on an ethic point, gnu/linux win since it hold a reference to the gnu
project and the fsf work.
on an historic point, linux win since everybody knows or had heard
about linux. but gnu/linux is rarer, despite rms advertising campaing.
don't misunderstand me: i respect a lot stallman's work; contrary to
many (mis-educated?) people, i don't see him as a fanatic; i see him
as the man who pushes the communauty in the right direction.
but on the gnu/linux point, the situation isn't as clear as he claims
it is.
why not forcing gnu/atheos, gnu/freebsd (for the ports part), ...
this is NOT coherent with forcing gnu/linux.
especially since you could replace the kernel with Hurd or BSD and from
the POV of the user (or programmer) there would be little noticeable
change but the GNU part would still be there.
nope, you would get a lot of bsd stuff in the os core ...
The GNU tools are the actual part the user (and programmer) will
interact with, be it bash, grep, gcc or glibc.
depending of the view point.
as a packager[1] and a developper, i massively use gnu tools :
compilation chain (binutils, glibc, gcc), emacs (development, mail,
newsgroups, diary, ...) but not only them : i also uses gnus and
various others packages for emacs, rpm, the kernel, windowmaker,
screen,
but for an end user, kde or gnome're far important blocks of the os...
and're not part of the gnu project _despite_ they're gpl.
one cannot account {g,}ui as basic os componant.
then, yes glibc is a big part, but as important to bootstrap the
systems as the sysv infrastructure (init, boot scripts, ...),
packaging infrastructure (rpm/urpmi or dpkg/apt), system maintenance
tools (reiserfsprogs, e2fsprogs, jfs-utils, util-linux, ...).
there'sn't just a majority: the gnu part is as important as other
componants of the os :-)
[1] as gimp packager for mandrake, i'll have to package gimp-1.3.x for
contribs in not so many time ... :-)
--
Still untested beyond 'it compiles' (davej)
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GNU/Linux vs. Linux
Simon Budig [EMAIL PROTECTED] writes: We should change it - to Unix. registered trademark :-( -- Still untested beyond 'it compiles' (davej) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [PATCH] mandrake patches dump
hello, i'm the gimp maintainer in mandrake linux distribution.
here're the patches i currently apply on gimp-1.2.3:
explaination note for a default that make perl programmers behave
strangely with gimp. by default, gimp perl modules doesn't export
functions, which makes perl programmers became fool ...
--- plug-ins/perl/Gimp.pm.orig Fri Nov 9 19:16:45 2001
+++ plug-ins/perl/Gimp.pm Fri Nov 9 19:17:14 2001
-651,8 +651,13
=head2 IMPORT TAGS
-If you don't specify any import tags, Gimp assumes Cqw/:consts main xlfd_size/
-which is usually what you want.
+If you don't specify any import tags, Gimp assumes
+qw/:consts main xlfd_size/ which is -NOT- usually
+what you want. You want to add :auto. You should thus
+use the following, for example:
+
+ use Gimp qw(:consts main xlfd_size :auto);
+
=over 4
this one is needed so that perl plugins're able to be compiled :
--- gimp-1.1.23/plug-ins/perl/Gimp/Lib.xs.perlpath Sat Jun 3 19:42:06 2000
+++ gimp-1.1.23/plug-ins/perl/Gimp/Lib.xs Sat Jun 3 19:42:55 2000
-1,4 +1,4
-#include config.h
+#include ../CORE/config.h
#include assert.h
#include stdio.h
--- gimp-1.1.23/plug-ins/perl/UI/UI.xs.perlpath Sat Jun 3 19:41:29 2000
+++ gimp-1.1.23/plug-ins/perl/UI/UI.xs Sat Jun 3 19:41:40 2000
-1,4 +1,4
-#include config.h
+#include ../CORE/config.h
/* dunno where this comes from */
#undef VOIDUSED
--- gimp-1.1.23/plug-ins/perl/Net/Net.xs.perlpath Sat Jun 3 19:43:04 2000
+++ gimp-1.1.23/plug-ins/perl/Net/Net.xs Sat Jun 3 19:43:09 2000
-1,4 +1,4
-#include config.h
+#include ../CORE/config.h
/* dunno where this comes from */
#undef VOIDUSED
--- gimp-1.1.23/plug-ins/perl/Gimp.xs.perlpath Sat Jun 3 19:41:48 2000
+++ gimp-1.1.23/plug-ins/perl/Gimp.xs Sat Jun 3 19:41:55 2000
-1,4 +1,4
-#include config.h
+#include ../CORE/config.h
#include libgimp/gimp.h
#ifdef GIMP_HAVE_EXPORT
this one forces the font selection dialog to only accept scalable
fonts (which isneeded since gimp forces the dpi of the font to dpi of
the image, and so fails on non-scalable fonts) :
--- gimp-1.2.2-pre3/app/text_tool.c.pix Sat Dec 16 20:38:38 2000
+++ gimp-1.2.2-pre3/app/text_tool.c Fri Sep 21 01:02:31 2001
-403,6 +403,13
{
/* Create the shell */
text_tool_shell = gtk_font_selection_dialog_new (_(Text Tool));
+
+ /* As we need fully scalable font, only accept scalable fonts */
+ gtk_font_selection_dialog_set_filter(GTK_FONT_SELECTION_DIALOG(text_tool_shell),
+ GTK_FONT_FILTER_BASE,
+ GTK_FONT_SCALABLE,
+ NULL, NULL, NULL, NULL, NULL, NULL);
+
gtk_window_set_wmclass (GTK_WINDOW (text_tool_shell), text_tool, Gimp);
gtk_window_set_policy (GTK_WINDOW (text_tool_shell), FALSE, TRUE, FALSE);
gtk_window_set_position (GTK_WINDOW (text_tool_shell), GTK_WIN_POS_MOUSE);
latest releases of wget print Resolving hostname... done which broke
some gimp assumptions (this patch also enforce old wget progress report):
--- gimp-1.2.3.orig/plug-ins/common/url.c
+++ gimp-1.2.3/plug-ins/common/url.c
-189,7 +189,7
putenv (LANG=C);
#endif
- execlp (wget, wget, -T, TIMEOUT, filename, -O, tmpname, NULL);
+ execlp (wget, wget, --progress=dot, -T, TIMEOUT, filename, -O, tmpname, NULL);
g_message (url: exec() failed: wget: %s, g_strerror (errno));
g_free (tmpname);
_exit (127);
-257,7 +257,17
DEBUG (buf);
+ /* New wget print Resolving hostname... done. */
+ if (fgets (buf, BUFSIZE, input) == NULL)
+ {
+ g_message (url: wget exited abnormally on URL\n%s, filename);
+ g_free (tmpname);
+ *status = GIMP_PDB_EXECUTION_ERROR;
+ return -1;
+ }
+
+
- /* The third line is Connecting to... */
+ /* The fourth line is Connecting to... */
gimp_progress_init (Connecting to server...
(timeout is TIMEOUT seconds));
-275,7 +285,7
DEBUG (buf);
- /* The fourth line is either the network request or an error */
+ /* The fifth line is either the network request or an error */
gimp_progress_init (Opening URL...
(timeout is TIMEOUT seconds));
i've also another patch that changes the dependancy on libmpeg to
libbmpeg but i won't submit it to you since not all distributions've
renamed mpeg_lib's libmpeg to libbmpeg (we did this in order to
prevent a clash with kdemutlimedia)
see you
--
ca fait pas homme d'aller voir le medecin (gc)
Re: [Gimp-developer] [PATCH] mandrake patches dump
Sven Neumann [EMAIL PROTECTED] writes: explaination note for a default that make perl programmers behave strangely with gimp. by default, gimp perl modules doesn't export functions, which makes perl programmers became fool ... I don't understand this patch nor the explanation you give. But then I don't know much about Perl. one of my coworker tried one day to write perl stuff for gimp but got mad since he wasted two hours before understanding the doc was wrong since some stuff didn't got imported into namespace, which is what use is intended to do. this one is needed so that perl plugins're able to be compiled : what is it you want us to say here? Perl plug-ins don't compile for you? yes. gimp-1.1.23 didn't fully compiles without this one, and since that day, we've always applied this patch. this one forces the font selection dialog to only accept scalable fonts (which isneeded since gimp forces the dpi of the font to dpi of the image, and so fails on non-scalable fonts) : this is only true if the user chooses to enter the size in Points. you see, distro maintainer job is to make programs that works for everybody :-) The gimp-1-2 CVS tree already has some changes that addresses this problem. See http://bugzilla.gnome.org/show_bug.cgi?id=58848 the bug really is that gimp try to apply image dpi to the font setting, and fonts don't provides/support all dpi settings. it'll work with classic dpi setting ... but not for everybody. if you create an image with a strange resolution *then* you'll enter the devil lands :-( as far as i can see, this has nothing to do with anti-aliasing but the fact that gimp blindy try to force font to enforce the image resolution even for non scalable fonts which cannot do this by definition. hence the patch. well, that's your problem. Shouldn't KDE use another name since libmpeg has been around for longer? Or am I wrong here? you're right: this is why i will never submit it to you as i said :-) Could you please check Bugzilla for existing bug-reports regarding your problems and attach your patches to these reports or open new bug-reports. Thanks a lot. humm. once the bug is spotten and a fix is availlable, i see no point to use such db but it's just my 2 cents. -- ca fait pas homme d'aller voir le medecin (gc) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] mandrake patches dump
Sven Neumann [EMAIL PROTECTED] writes: well, my position in this thread is a bit biased since me and other GIMP developers have spent lots of their free time hunting down bugs that turned out to be caused by buggy GTK+ themes Mandrake used to ship. which ones ? i've only got bug reports about crash caused by eazel gtk engine. if you want me to fix something, mail me :-) Please excuse if I've sounded harsh, but you can upset most core gimp developers just by silently mumbling the word Mandrake when they're around. i don't understant mubling This is no personal offense and I promise I'll try hard to restore a neutral position regarding Mandrake. well, our goal is the same: making the world better through free softwares, so if i can do something so that gimp developpers get happier, just tell me. -- ca fait pas homme d'aller voir le medecin (gc) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] mandrake patches dump
Raphaël Quinet [EMAIL PROTECTED] writes: The details are in http://bugzilla.gnome.org/show_bug.cgi?id=55735 This has been fixed in Mandrake 8.0 one year ago, but we still got a duplicate bug report related to it this year. And it took a while for us to figure out that these apparently unrelated bugs were all caused by the broken GTK+ theme shipped in the default Mandrake distribution. Not a big deal, but annoying anyway... ok, i just looked at mandrake_desk changelog, we speak about the same bug, ie the eazel themes bugs... you then know who dit it ... :-) i didn't understant at first since you speak about default mdk theme whereas : - the only bug of this specie i known whas eazel one - the installation just install some packages in each packages sections selected by the user in newbie installation. but this term was used by mdk updates team well, our goal is the same: making the world better through free softwares, so if i can do something so that gimp developpers get happier, just tell me. On a more serious side, you could try to convince the KDE developers to avoid using the name libmpeg that conflicts with the original libmpeg that has been around for quite a while. This would avoid some compilation problems on Mandrake systems. [tv@ke rpm]$ urpmf libmpeg kdemultimedia:/usr/lib/libmpeg-0.3.0.so kdemultimedia:/usr/lib/libmpeg.la kdemultimedia:/usr/lib/libmpeg.so the problem is that now they'll probably claim it'll break source compatibility... :-( and worse, one of the kde project goal is to remains binary compatible in Y branch. the question is: is kde's libmpeg only used in kdemultimedia ? if yes, this may be fixed in a simple manner. i've already made them changed their mind when i was ImageMagick maintainer: mosfet just put ImageMagick in kde because he wanted to use an altered version of it ... i noticed it immediatly whan it conflicted with libMagick5-devel :-( hopefully they've stopped to do this. but others projects (eg mplayer) continue to cvs_steal other projects (but at least mplayer doesn't comew with shared libs that would conflicts) Ça dépend du type d'opérations pratiquées par le médecin... i won't translate for those who don't undertand french :-) -- Toutes les grandeurs de ce monde ne valent pas un bon ami. (Voltaire) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp binary size
Michael Natterer [EMAIL PROTECTED] writes: Yes, that's exactly the reason for the insane size. You probably use gcc 3.2?? I noticed the same some days ago. this is not related to the gcc version but to the default cflags. as for now, most packages come with -g or -g -O2 as default cflags due to the autoconf suite default, which is plain right for debugging. with the same cflags, gimp-1.2 is 2.0Mb (1997900 bytes) in current mdk cooker and gimp-1.3 is 2.3Mb (2323564) in current mdk contribs. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-perl-cvs status
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: is it worth building the gimp-perl module from cvs yet? Depends on what you are needing it for. The evrsion in CVS seems to be fully working, except that none of the examples that use their own Gtk+ interface have been converted to gtk2 yet, and coredump. gtk2-perl binding is quite usuable now and conversion is not so difficult. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
Dave Neary [EMAIL PROTECTED] writes: Another reason may be that it is difficult to build the development version because it depends on released versions of some libraries that are not included yet in the major GNU/Linux distributions (e.g., GTK+ version 2.2.2). both debian unstable, mandrake and redhat provides gtk+2.x for quite a long time. there's no problem in providing both gtk+-1.2.x and gtk+-2.x in a distro. Also, the number of dependencies for GIMP 1.3.x is much higher than the number of dependencies for GIMP 1.2.x, so it is more difficult to have a working build environment for the 1.3.x version. this is a valid point for: - users of very old distributions - non developer users (that is most end users) - windows users (for which getting both a working development suit and enough knowledge to build something with required dependancies is probably not easy) Do we need binary distributions? There was a discussion about binary distributions. This may help people to try some versions of the GIMP (especially the development versions) without having to compile everything. However, maintaining binaries is a lot of work, even if we only maintain binaries supplied by others. In addition, this would bring some additional responsabilities that we do not want to have. For these reasons, it was decided that www.gimp.org would not host any binaries but would link to the pages of those who are providing binaries for various platforms. yes development and packaging (well binary tarball is some kind of packaging) are two different tasks. you can either: - leave it to distributions (after all gimp-1.3 is already provided in mandrake contribs and in debian unstable) - leave it to a nightly build system (see mozilla) - leave it to another specialized team (aka you need one people that sometimes build windows binaries and someone who sometimes build static gimp for linux) Is Bugzilla too hard to use for new users? -- It was suggested to make it easier for users to submit bug reports, for example by having an e-mail address to which bug reports can be sent without having to register to Bugzilla (we already have such an address, although it is not widely known). This proposal was rejected because most of the bug reports (especially from new users) are incomplete and require additional information. If the user does not have a Bugzilla account, it is not possible to rely on the automatic notification system to send messages to the user when a comment is added to their bug report or when the status of their bug report changes. even if bug reporting by mail may not look suitable, being able to anwser bugzilla by mail is a must. it saves quite a lot of time and is often see as more easy to use by developers (at least here at mdk). there're several extensions that do this (see freshmeat.net or soft/bugs module in mandrake cvs). ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
Raphaël Quinet [EMAIL PROTECTED] writes: Another reason may be that it is difficult to build the development version because it depends on released versions of some libraries that are not included yet in the major GNU/Linux distributions (e.g., GTK+ version 2.2.2). both debian unstable, mandrake and redhat provides gtk+2.x for quite a long time. The current GIMP requires GTK+ 2.2.0 and recommends 2.2.2 (this will be required by the next version). Unfortunately, many users of the distributions mentioned above are still using GTK+ 2.0.x, not 2.2.x. Besides, the majority of the users are not using the latest version of their distribution. - current debian unstable = 2.2.2 (2.2.2-3) - current mandrake cooker = 2.2.2 (2.2.2-6mdk) - current rh rawhide = 2.2.2 (gtk2-2.2.2-2.1) mdk9.2 is scheduled to be released on septembed, i do not remebed exact date for rh but it's supposed to be at the same time. debian is expected to be releasd on december. so this issue may not be a real one. you're left to few classes of users: - those who use only distro packages: they will wait until a binary package is availlable - those who know how ot build programs: they're supposed to know how to build dependancies and anyway, maybe adding a few ifdef round gimp code using specific 2.2.x features if it can safely be disabled may help users of older releases or other distros. Also, the number of dependencies for GIMP 1.3.x is much higher than the number of dependencies for GIMP 1.2.x, so it is more difficult to have a working build environment for the 1.3.x version. this is a valid point for: - users of very old distributions - non developer users (that is most end users) - windows users (for which getting both a working development suit and enough knowledge to build something with required dependancies is probably not easy) This is not only about users of very old distributions. The world is not only Linux and Windows, and the Linux world is not only made of binary distributions. agreed. Assuming that a system has at least some basic tools such as make and a compiler, building GIMP 1.3.x adds 27 dependencies (or 32 if you are a developer who also needs libtool, autoconf, etc.) Compare this with GIMP 1.2.x, which had only 11 dependencies (or 14 for developers.) factoring features around all tools is nice even if it's bring more dependancies. sure it's Even if we could create the binary packages, I don't think that we should distribute them from the GIMP web site. This means that we would get support questions for these binaries. We already get some distribution-specific bug reports from time to time, but we can usually divert them to a more appropriate place. Supporting the binaries is not something that most developers would enjoy doing. So it is better if someone else can take care of building and distributing binaries for us. This can be a Linux distributor or some individual who puts the binaries on his web site (like it is currently done for the Windows version). so since, most oses are in one of the following states: - already provides gimp-1.3.x somewhere (debian unstable, mandrake contribs) - is ready for gimp-1.3.x regarding dependancies (redhat) - some site provide prebuild binaires (windows) and since other oses are either small regarding number of users or their users are expected to know how to build something (eg: those who already build gimp on solaris like you) are able to deal with a few more dependancies that are anyway needed for other programs, i think this issue can then be closed and this feature be not provided by gimp.org. We would be glad to link to these sites from the GIMP web site, but it is better to avoid hosting any binaries on www.gimp.org. though, this web site could then figure some url to get binaries for most people (either distros packages or tarballs from third parties) [maybe it exists already, i didn't check it out] As far as I am concerned (I spend several hours per week on Bugzilla), I don't think that answering Bugzilla by mail would really save time. For every third or fourth bug to which I respond, I do a Bugzilla query to find related bugs. Since I use the web interface for queries, I don't think that I would save much time by using e-mail for the other bugs. well, ones can use its bugzilla mail box for such queries :-) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
Sven Neumann [EMAIL PROTECTED] writes: and anyway, maybe adding a few ifdef round gimp code using specific 2.2.x features if it can safely be disabled may help users of older releases or other distros. We did that for a while. It not only became difficult to maintain but at some point it became apparent that gtk+-2.0 just had too many bugs that could not be worked around. The current code still has some ifdefs that enable workarounds for bugs in gtk+ before version 2.2.2. We do this in order to avoid a dependency on 2.2.2 but at some point before gimp-2.0, we will have to drop these workarounds and depend on gtk+-2.2.2 or newer. sure, when woraounding old bugs became too much development time consuming, it's better to just bump the requires. what's more, the odds are high that all distributors that will ship gimp-2.0 will ship gtk+-2.2.x too ___ 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
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
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
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] gimp2-freetype
Sven Neumann [EMAIL PROTECTED] writes: Hi, Thierry Vignaud [EMAIL PROTECTED] 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 ? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp2-freetype
Sven Neumann [EMAIL PROTECTED] 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). ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
