[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#600210: Freeze Exception: libgda4

On 25.10.2010 20:36, Adam D. Barratt wrote:
Which of the fixes mentioned in upstream's changelog does the above
refer to?

* libgda/gda-debug-macros.h, libgda/gda-transaction-status.c: Removed
	internal debug macros

Both of those changes are to code which is in "#ifdef GDA_DEBUG" blocks.
Surely not everything builds with GDA_DEBUG turned on?


It's not about building or code itself.
g-ir-scanner (and friends) generates GIR files, parsing the code.
Part of #ifdef has been removed because of obvious g-ir-xyz tool issue.
Not GDA library one.

Besides, many developers who build applications on top of libgda
complains about this library, not being up to date in available official
repositories. Libgda is the only one, open source library which provides
common access to databases, and thus should be available with minimal
amount of bugs.

"People will complain if its out of date" is not a valid reason for a
freeze exception.  Besides, if upstream release 4.0.13 in a little
while, why won't people just complain about Squeeze not including that

I fully understand Your point of view. But I do not mean keeping library up to date, sacrificing some stability. On the contrary. I mean, no single application or library (which utilizes GIR functionality) can *be built* on top of GDA without this issue being resolved.

One can provide workarounds as long as library is working.
But no one can provide workaround as long as derived application/library can not be built at all. That's why I am saying, this bug is critical.

If I can not build my application or library on top of other included in Squeeze, it means package in release has a bug, which should be fixed. And I think it's better to do this now.

Possibility to build application is fundamental case.
The same as GIR is nowadays for Gnome or software built on top of GLib/GObject.


Reply to: