Hi Marcel, On Thu, Jan 3, 2013 at 1:42 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > Hi Luiz, > >> >> In that case I would just revert back this patch, but the >> >> documentation actually say g_slist_free_full is available since 2.28 >> >> http://developer.gnome.org/glib/2.28/glib-Singly-Linked-Lists.html#g-slist-free-full >> >> so I wonder what is going on. >> >> >> > >> > The problem now is g_queue_free_full() not the g_slist_free_full(). >> >> Right, but it is quite the same situation and I don't get why we don't >> just update, by the time distros start to package BlueZ 5 glib 2.32 >> wont be a problem, in fact it should not be a problem right now as it >> is about a year old release: > > because every new GLib release drags in more dependencies. It is a bit > out of control. So requiring the 2.32 comes at a cost that I am not > willing to pay right now. We already have seen this with ConnMan where I > accidentally used a newer GLib function that was not present in a 2.28 > and before. It is pretty hard for embedded system to do these kind of > upgrades when their dependencies and thus footprint and memory > consumption increases for just a simple convenience function. It seems the mandatory glib dependencies are restricted to libffi, pkg-config and Python: http://www.linuxfromscratch.org/blfs/view/svn/general/glib2.html Anyway regardless if we do update or not, I don't see why g_queue_free_full is different than g_slist_free_full, so instead of converting everything to g_queue_foreach + g_queue_free why we don't bring back glib-compat and do this in one place as we did for g_slist_free_full? -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
