So there is, at the moment, a disagreement between the gnucash and glib developers about whether the keyfile interface is even a supported interface, with Josselin now suggesting that the glib maintainers simply won't support the use of keyfiles by applications (despite it being documented). And, the documentation before the change clearly allowed spaces in key names; and even addressed the questions raised about "why spaces may be hard" (leading spaces, spaces around the equal sign) and disambiguated the syntax. I cannot fathom why, given that the previous behavior was documented as a published interface with a defined syntax, such a significant change to the syntax, and statements like "we will never support this interface" do not constitute such significant changes to the ABI that an soname bump is called for. I do not want to be in the middle of this. I trust that the release managers will decide what they want in the release, whether it's a broken gnucash or whatever other mysterious bugs the glib people keep saying are fixed by this change. Eventually upstream gnucash and glib will match. That isn't in doubt, and I leave it to them to duke it out. This is an excellent example of the whole *point* behind a freeze, which is not to make "harmless" changes, since even "harmless" changes sometimes turn out to have very serious consequences. In the absence of an soname bump, it is clear that gnucash does not work with glib version 2.12.5 and higher. If it would not cause disasters, I would upload a conflicting source package today, but it would in fact cause disasters. What I would like to see is some clear indication from the release managers what *they* think should be done; so far the rest of us can go around and around, but it isn't producing much resolution. Asking upstream has only showed that the rift is deeper than was earlier apparent. I would like to be *out* of the middle; I want the glib people to talk to the gnucash people directly, and I want the release managers to start saying what *they* think should be the resolution so that we can get to implementing it. I have the sinking feeling that I won't get what I want about either of these. Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part