[FFmpeg-devel] Round 2: Symbol versioning

Reinhard Tartler siretart
Tue Dec 29 10:54:16 CET 2009


Michael Niedermayer <michaelni at gmx.at> writes:

> On Mon, Dec 28, 2009 at 04:07:02PM +0100, Reinhard Tartler wrote:
>> Diego Biurrun <diego at biurrun.de> writes:
>> 
>> > On Sun, Dec 27, 2009 at 10:35:14AM +0100, Reinhard Tartler wrote:
>> >> [...]
>> >
>> > Please remind me why you are not patching the linker even now that
>> > Michael has handed you a patch for it..
>> 
>> Because:
>>  - Michael admits himself that his patch does not adress the root of the
>>    problem ("breadth first search starting from the application").
>
> Its hard to change this and while i could imagine my bugfix patch to be
> accepted upstream once its tested and checked a bit more and submitted
> i have my doubts that changing the search order would be accepted.

Agreed.

Moreover, I'm pretty sure that this change would break many existing
applications that rely on the current behavior of ld.so.

>[...]
>>  - I'm still unconvinced that there is a serious problem at all:
>>    The situations Michael's patch adresses are (AFAIUI) easily and
>>    effectively avoided by using debian's shlibs system [1].
>
> shlibs AFAIUI just make sure that every package that has been (re)build
> against a lib will depend on a specified range of versions of that lib.

Okay, I guess that I need to recap at this point the shlib system:

 - it is unique to dpkg based distros, I haven't seen something similar
   in rpm based distros yet.

 - every shared library in debian based distros is *required* to
   implement a shlibs file 

 - The ffmpeg package shlibsfile needed a versioned depends since ages
   -> no additional overhead here

 - it is fully automated for applications packages. They just put in the
   depends line a substvar like 'Depends: ${shlibs:Depends}' and it will
   be filled in automatically at build time of the binary package

> Thus if you introduce a libavutil with same soname but enabled versioning
> and with the shlibs stuff set correctly by hand
> any package rebuild with it could not be installed as long as an older
> libavutil of that soname was installed.
> An update to one with versioning
> would be required if a rebuild application or lib where installed.
> This should prevent 1 of 3 bugs in ld.so 

correct

> at the expense of hundreads of otherwise unneeded dependancies.

these dependencies are already implemented archive wide, so the absolute
number of (versioned) dependencies does *not* increase.


> But at this point you have not introduced the new libavutil with new
> ABI and new soname.

Indeed.

> Thats something you have apparently postponed for later and i wonder
> how you plan to do it without hitting bugs 2 and 3 It sure can be done
> with many additional (otherwise unneeded) dependancies

That depends on several factors, mainly on how fast this transition will
be implemented and at what stage of the release cycle for the respective
distro we are.

I'd really like to get this deployed distro wide first and decide then
how to proceed from there afterwards in order to avoid mixing too many
(related) issues unnecessarily.

> and i claim that its very easy to miss some of these dependancies and
> in the end what you create with all these dependancies is not that far
> from the rebuild the world you are trying to avoid.

I claim that this is not true, because of the mechanics of the shlibs
system and me as package maintainer, but this is something that has to
been shown by practice, not theory?


>> 
>> Besides, the whole stunt is coordinated with the debian release team[2],
>> who have supervised many similar transitions before. I'm therefore very
>> confident that the current approach (w/o patching the linker) is proven
>> (and therefore "good enough") for debian.
>
> Its also proofen one can swim across the english channel, still trying to
> make this an argument that this method of crossing the channel is "good
> enough" is probably only successfull as british humor

I'm not a native speaker, I meant prooven as in "bew?hrt", not
"bewiesen" (both german)

>> The issues Michael is adressing seem to me rather farfetched and very
>> unlikely to occur in the field when deploying them in debian in the
>> way I intend to do. For ffmpeg upstream, I can see no regressions
>> either.
>
> The issues arent much more farfetched than the ones you try to fix with
> introduction of versioning

Well I can show you dozens of bug reports that shows that people *are*
already hit by the problem I intend to fix with symbol versioning. The
issues you adress of course also exist, but are way less likely to occur
in practice, and impossible to hit if you follow the recommended (as in
the release notes) upgrade procedures closely.

> Besides with my patch introducing versioning should become a much simpler
> task without all the unexcpected dependancy needs. That sure would make
> the release teams work and all involved maintainers work easier for future
> such changes ...

Yes, and that's why I think they shouldn't be implemented in debian
only, but in binutils/glibc upstream. But then we probably have to deal
with Drepper?


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4




More information about the ffmpeg-devel mailing list