Bug#404888: glib destabilization and ways forward

[Marc 'HE' Brockschmidt]

Josselin Mouette <joss at debian.org> writes:
> Le vendredi 29 décembre 2006 à 10:48 -0800, Thomas Bushnell BSG a écrit :
>> 1) Decide that glib should not migrate into testing (it is a freeze,
>> after all); if there are particular fixes of RC issues in more recent
>> versions, then those fixes should be added, but otherwise the wholesale
>> importation of many changes should not be permitted.
> 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.

It is no regression over the prior situation and was never reported in
the BTS, even though GKeyFile was "broken" (ie too liberal when taking
input from application) in this way for some time.

>> 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.

We don't know which other applications may rely on gkeyfile without
input checking. I don't want to find out at this point of the release
cycle, so this is not an option.

>> 2) Decide that glib can migrate into testing, with the particular change
>> of checking key values reverted to its pre-2.12.5 behavior, since this
>> is a destabilizing change in the Debian context.
> Same answer. At least we can get the other bug fixes.

I would prefer to leave the new input validation routines in place, but
replace all current "return FAIL" in the new g_key_file_is_group_name
and g_key_file_is_key_name function with g_warning("'%s' is not a valid
GKeyFile key/group name", bla) and only do a return FAIL if the old
condition (string is empty) was met. Of course, reverting to the old
version would also be an option.

Marc
-- 
BOFH #121:
halon system went off and killed the operators.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20061230/b509bb14/attachment-0001.pgp