Re: Versioned symbols for 3.0?

[Behdad Esfahbod <behdad esfahbod gmail com>]

On 05/18/2010 01:43 PM, Matthias Clasen wrote:
> On Tue, May 18, 2010 at 12:58 PM, Behdad Esfahbod
> <behdad esfahbod gmail com> wrote:
> 
>> If we autogenerate the version script, I think Matthias can be bribed into
>> accepting it
> 
> Well, the arguments against symbol versioning have not really changed
> since ca 2005, so we do we need to discuss this again ?

I think limited use of symbol versioning can fix real problem without
introducing new ones.

> - It doesn't really work the same way on any other platform

We can use it in a way that it only adds extra features, not in an
incompatible way.

> - It can only version functions, we still have have unversioned types,
> properties, signals, etc, etc.

It does fix a real problem that has no solution currently: when glib macros
are changed to use newly introduced functions (like it happened in the case of
g_return_if_fail, and recently for g_new, and will definitely happen in the
future again), a program, without any source change, will require a newer
version of glib runtime just because it was compiled against the new version.
 I definitely have got bug reports in Fedora for this, and I don't know of any
way to fix it in RPM-based systems.

The proposed scheme beautifully fixes the above problem and I don't know of
any other problems it introduces.  I read the links you posted, and still
don't see anything against it.

It's not meant to replace any current means of requiring glib versions.  It
just fixes the very specific case mentioned above.


On 05/19/2010 05:05 AM, Alexander Larsson wrote:
> On Tue, 2010-05-18 at 20:30 +0200, Patryk Zawadzki wrote:
>
>>> - It can only version functions, we still have have unversioned types,
>>> properties, signals, etc, etc.
>>
>> It's only able to version exported symbols and I wouldn't ask for
>> anything more than that. I didn't mean to propose dropping the API
>> documentation, just making our lives a little easier.
>
> That makes it useless though. If an app uses a new signal but not a new
> symbol then symbol versioning won't detect that a new glib is needed, so
> you can't trust it anyway.

It's a one-way thing.  If the symbol-versioning tells you that you need glib
>= 2.28.0, you REALLY REALLY need it, or your program doesn't run.  Doesn't
matter what the module developer thinks.  The binary requires glib >= 2.28.0
because of the way it was compiled.  The module developer has not control over it.

> Also, many times apps rely on e.g. a newer version of glib fixing an
> issue with a function. That doesn't make the function "new" so it won't
> get a new version (typically), so again the symbol versioning isn't
> enough.

No one claimed that it's enough.  It's one more requirement we need to handle.


I'm with Patryk here.

behdad