On Sat, 2006-12-30 at 17:15 +0100, Josselin Mouette wrote: > Le vendredi 29 décembre 2006 à 10:48 -0800, Thomas Bushnell BSG a > écrit : > > Despite what Josselin has said, I can see no indication from a brief > > perusal of the upstream branch sources in trac that upstream gnucash > > either no longer uses these key files or has changed away from the keys > > with embedded spaces. > > Then they must stop using GKeyFile. There is no way that they will get > this supported by GLib developers. This is an advertised interface for glib. If you want to change that, it requires an soname bump. > That leaves us with the silent data loss that can happen when using > broken key names (like, well, gnucash does). Whether this is or not a RC > issue, I'll let the release team decide. As upstream gnucash has pointed out, in the message I just forwarded, the previously advertised interface *did* make spaces legal in key names. > > 3) Decide that glib can migrate into testing with the destabilizing > > change intact, migrate an upstream gnucash fix into testing at the same > > time. > > This is the sanest solution because this is the one that gets us with > the lesser number of bugs. As it turns out, if upstream gnucash is correct, this *is* a substantial change to the *advertised interface* for the functions. Now you are saying the functions must not even be used at all, and yet, you are documenting them! Please decide what you want the interface to be, and since clearly you want something different from the previous one (whether prohibiting use of key files or changing the syntax of keys) bump the soname. Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part