Raphaël Quinet <quinet@xxxxxxxxxx> 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 :-)
