On Sun, Jun 25, 2006 at 01:15:31AM -0700, Jon A. Cruz wrote:
On Jun 25, 2006, at 12:31 AM, Ralf Stephan wrote:
Fedora Core 4. Possibly CentOS 4.2 (see bug 1505373)?
Let me stress that the recent problems with compiling 0.44 on FC4 only happened because NO SINGLE PERSON tested the prereleases with a pure glib-2.4 system.
True...
But then again, that's mainly that no single dev or cutting edge person tested it. I'm not too surprised if those willing to test pre- releases are a bit more advanced than some common users.
Given that Fedora Core 5 only just came out, we might want to look at things a bit.
I've emailed the gtkmm list to see if Murray has this data handy.
Hmm, seems like there ought to be some site where all the versions of dependencies are listed, for all major distros. Anyone know of such a thing? If there isn't maybe I should suggest OSDL do it (ISV's probably need it even more than us).
More importantly, I think the CentOS 4.2 problem is a more telling one. I'm pretty sure that it's corresponding to RedHat Enterprise 4.x, so is still a very prevalent platform for end users (at least of the corporate type). RHEL, RHAS, NLD, SLES and friends might be the "trailing edge" we should keep an eye on supporting.
I noticed Gentoo has it, and I think has had it for a while - it was just that one system where I noticed this bug; my other systems already had the newer gtkmm on it. It's sort of strange having inkscape be about the only application I have installed that requires gtkmm...
I agree that looking at the enterprise distros is a good way to judge what is mainstream, however do keep in mind that the way enterprises work, it's unlikely they'd be allowing users to install latest inkscape until it's included in the distro, too. For this situation, I'd actually think it more appropriate to check that inkscape's autopackage installs cleanly there (if anyone happens to have a copy of it).
Also, regarding the enterprise distros, I don't know exact release plans, but I gather they'll all be finalizing the versions in their next releases prior to when we'll be ready to release 0.45. We'll probably even have time to get a few stable releases out before then too, which enterprise users will probably value much more.
Anyway, so while I agree looking at RHEL, SLES, etc. is worthwhile, I suspect timing-wise it works out well for us to upgrade gtk now.
Ok. Just did a quick check. http://www.redhat.com/rhel/
Red Hat Enterprise Linux 4 was only released in Feb of 2005 (just over a year ago). They also provide seven years of support for each version. That might be a little long for us, though. But the more important factor might be their 18 month version plan. That means RHEL 4.x is still the latest-and-greatest.
Okay, so 18 months from Feb '05 is Aug '06, and that fits with what I've heard. So we've done good by getting 0.44 out with plenty of time for them to test and include, but 0.45 will come after. However, possibly the new RHEL will have gtk 2.8 anyway?
And... checking CentOS 4's OS download rpms seems to show GTK+ at 2.4.13.
Hmmmm..... so I think we don't have 5 coming up to beta 'till next month, with actual release scheduled for December. With that in mind, we might want to see if we can wait on the bump until 0.46 intead of 0.45. I'm thinking that might be one way to approach it given that we probably want to do quicker releases this time and get two done in the next six months.
If we do decide to stick with 2.4 for 0.45, we ought to make sure we still have some devs (or at least some test machines - we can keep the nightly build machine set to 2.4 I think) that still compile and/or test against 2.4, to keep us straight... It's getting pretty easy to slip and use newer features...
Oh, another driving platform as far as I'm concerned would be OS X. That's my main OS at the moment, so I have ulterior motives for keeping it build-able there. :-) At the moment, fink is only up to GTK+ 2.6.10. http://pdb.finkproject.org/pdb/package.php/gtk+2
Now.... if some people were to help getting native GTK+ working well on OS X, then that would free at least that particular dependency. It *might* be practical for a 0.46 timeframe, but not 0.45 (though good enough for devs might be doable in that timeframe).
Hmm, this is a good point; knowing how long it took to get gtk going on osx, I'd hold this as pretty important.
Bryce