Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
- From: Behdad Esfahbod <behdad behdad org>
- To: Josselin Mouette <joss debian org>
- Cc: desktop-devel-list gnome org
- Subject: Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
- Date: Tue, 15 Jun 2010 09:36:39 -0400
On 06/15/2010 09:27 AM, Josselin Mouette wrote:
> Le mardi 15 juin 2010 à 08:21 -0400, Behdad Esfahbod a écrit :
>> So, my application uses libraries A and B. It takes a GtkWidget from A, and
>> passes it to a function in B. If A links against gtk-2.0 and B links against
>> gtk-3.0, tell me exactly how does symbol versioning address this?
>
> It doesn’t, of course. It will not magically solve all coinstallability
> problems, just a subset of them. As soon as the application exposes
> widgets from both libraries, you’re pretty much doomed.
So, which problems *does* it solve? (except for inferring minimum version of
the library required at runtime)
Isn't GTK+ by nature designed such that all widgets eventually are painted by
on version of the library, and hence simply no way to have two in process
without passing structs from one to the other?
Plus, what would you do to glib's type system? Only one of the Gtk's can add
the gtype "GtkWidget". Which means, it wouldn't work even if not passing
structs from one version to the other...
>>> Do you really think GTK+ is the first library with which we encounter
>>> such an issue?
>>
>> What are some other examples that are parallel installable and use symbol
>> versioning in the way that was proposed on this list?
>
> For example there’s libpng, and libjpeg is underway. But of course this
> won’t solve cases of passing a libpng structure from a higher-level
> library to another one.
Lets be fair: those use cases are inherently much simpler and much more
limited and contained.
behdad
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]