Request: require glib2 >= 2.12

[Geert Janssens]

On Saturday 20 February 2010, John Ralls wrote:
> On Feb 19, 2010, at 2:24 PM, Geert Janssens wrote:
> > I'd like to bump the minimum required glib2 for the 2.3.x series to 2.12.
> > The reason is that I'm trying to solve a bug with database passwords that
> > contain ':' characters. This interferes with the code that uses ':' as
> > separator for the database parameters.
> >
> > My solution would be to encode the password in base64 before saving it
> > and to decode it when required.
> >
> > However, the base64 glib functions only appear in 2.12.
> >
> > I think this bump shouldn't be any problem, because all distributions we
> > care about have at least this version.
> > * The distro with the oldest glib version is (as always) RHEL5. It
> > currently ships 2.12.3. Debian Lenny (the oldest non-EOLed-Debian) comes
> > with 2.16.x. All others are more recent.
> > * The windows build uses 2.22
> > * Fink carries 2.20, MacPorts 2.22, I can't immediatly find what John
> > uses for his MacOSX builds, but I'm pretty confident it's more recent
> > than 2.12.
> >
> > So in practise it won't affect any of the targeted platforms, yet allows
> > 1. the use of the base64 functions
> > 2. a cleanup of several HAVE_GLIB_2_{8,12} conditionals that are never
> > triggered anyway.
> >
> > As usual, the question: any objections ?
> 
> John uses glib 2.22 for OSX. You can see everything I use in the jhbuild
>  modulesets at http://github.com/jralls/gtk-osx-build and
>  http://github.com/jralls/gnucash-on-osx (gtk-osx-build/modulesets-stable
>  for production use; there's only one gnucash moduleset).
> 
That's good to know. Thanks.

> I think we need to be worrying more about what Gnome is up to and keeping
>  up with their changes than with making sure we can run on 5-year-old
>  versions. Users of the more aggressive distributions are going to be
>  pretty upset in a year or two if Gnucash won't run on the latest Ubuntu or
>  Mandriva because we depend on libraries that aren't in Gnome anymore.
> 
I do agree with you here.

The trick is to keep RHEL5 in the running while not running too far behind on 
the more aggressive distros. RHEL5 is very conservative in it's packages, but 
still active and not EOL. So IMHO it's worth continuing to support it.

I have already requested package updates on the RHEL bugtracker in an effort 
to keep it from running too far behind. But so far, there's not actual updates 
yet.

Geert