[vlc-devel] [RFC] Slimming LibVLC down

[Rémi Denis-Courmont]

On Mon, 1 Feb 2010 16:05:08 +0100, "Pierre d'Herbemont"
<pdherbemont at free.fr> wrote:
>>> Well, depending how you link, if you don't use deprecated function
>>> you are safe.
>>
>> That's simply not true.
> 
> No. "if deprecated function and how you link" is the important part.

There are exactly *two* ways to link:
 - dynamically (then you are wrong),
 - statically (then it is irrelevant).

> Below you just agree with this.

>> In practice, this does not work. You will silently break applications
>> that do use the deprecated symbols. You will also not fool
>> state-of-the-art packaging systems who do track exported symbols.
> 
> Remi, I stated, that *if* you don't use deprecated stuff you are
> fine...

The library does not know what its reverse dependencies use (*obviously*
need I mention).
That wouldn't make any sense.

Did I mention that some packaging systems keep track of exported symbols
and will detect an error? Oh yes, I did.

> Don't you think we should look forward having a stable API?
> Ie, deprecate stuff and let user move gently to the new API? I don't
> mean for 1.1 as we have already gone too far.

You can't do that. For the umpteenth time, removing an exported function
breaks compatibility. That's just how dynamic link resolution works.
Whether or how long a function has been marked as deprecated by the time of
removal, is totally irrelevant.

> I think we should balance. And we need to be a bit pragmatic with
> this, and leave the religion aside.

Yes, lets be pragmatic and follow the way real-world dynamic library link
resolvers work and packaging system keep track of versions.

Not the way you wish they did.

-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis