[FFmpeg-devel] Round 2: Symbol versioning
Thu Dec 31 10:33:45 CET 2009
Michael Niedermayer <michaelni at gmx.at> writes:
> On Tue, Dec 29, 2009 at 11:35:22PM +0100, Reinhard Tartler wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> > On Tue, Dec 29, 2009 at 10:54:16AM +0100, Reinhard Tartler wrote:
>> >> Michael Niedermayer <michaelni at gmx.at> writes:
>> >> > 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?
>> > I understand how the shlibs system works around the assertion bug, i dont
>> > see how it will help against the other bugs.
>> Bug #2 can only happen if a (packaged) application can have the same
>> symbol loaded one time with and one time without symbol versioning. With
>> the *current* upgrade paths this cannot happen, as the shared libraries
>> with versioned symbols will replace the old ones at the same moment as
>> they are installed.
>> The only way this situation could occur is if we would target getting
>> libavutil50 for the next Debian release (squeeze). I don't do that
>> currently for several reasons; one is the issue at hand, we can discuss
>> the other ones in a separate thread.
> I dont understand why next or "next after it" makes a difference?
> You postpone introducing libavutil50 but the issue stays the same
The difference is that Debian does not support "skipping" releases, this
considerably reduces upgrade paths. This means that if we succeed with
finishing this transition in time with the release of squeeze, I can
safely assume that from there on, there will be no library and no
application without references to the versioned symbols. This will
effectively prevent bugs 2&3 to happen in practice.
>> Even if we would target libavutil for squeeze, there would still be a
>> standard practice for shared library packaging as I already indicated
>> before. I wanted to avoid annoying you with these details, but it seems
>> you are interested in them anyways: rename the source package
>> libavutil49 to libavutil49v or something and make it conflict against
>> libavutil49, as described in section 3.3 of . Please note that this
>> is not an ad-hoc solution, but a procedure that has been used for other
>> libraries before. Since this is rather disruptive and I don't see the
>> necessity for this, I'd like to avoid it if I can.
> Its sure disruptive and getting closer to rebuild the world or maybe you
> are already there ...
> but i dont think this is enough to avoid the bugs 2&3
Okay, let's do this gedankenexperiment:
> libavutil49 (installed)
> libavutil49v Conflicts libavutil49 (but the user did not install this because
> it would force him to uninstall many of his favorite applications)
Goal of the transition is to get all applications recompiled so that
they depend on libavutil49v. However there is indeed a transition period
(which is actually the whole point of the exercise), in which the
application is supposed to not break.
> libavutil50 (installed)
Okay, let's assume we would upload a post 0.5 version (current trunk)
for squeeze (which I currently don't intend to do), then we would need a
2nd transition, namely from libavutil49v to libavutil50.
However, we would never start this 2nd transition before the 1st one is
(BTW, the main reason for not mixing these transitions is because of the
rules applied by the testing migration script that decide when a package
is copied from 'unstable' to 'testing', but these details shouldn't
matter here, I think. In any case this example shows that serializing
the two transition also effectively avoids bugs 2&3).
> favorite_app depends on libavutil49
> favorite_app depends on libfoo0
this means that favorite_app has not done the 1st transition...
> libfoo0 1.0 depends on libbar0
> libbar0 uses versioning
> libbar0 1.0 depends on libavutil49
> libbar1 2.0 (installed) depends on libavutil50
but libbar1 has started the 2nd one. Not something that will happen in
practice for the reasons indicated above.
> libfoo0 1.1 (installed) depends on libbar1
> now the user has:
> favorite_app -> libavutil49
> -> libfoo0 -> libbar1 -> libavutil50
> libbar1 will be linked to libavutil49 though
> Maybe i did miss some rule but even if so it feels quite fragile
> the simplest solution would be to make libavutil50 conflict with libavutil49
> but thats not going t make it less disruptive ;)
Less disruptive than what? I think that would be an adequate solution in
order to prevent this situation in case some (stupid) 3rd party archive
decides to start the 2nd transition (49v->50) before the 1st one.
BTW, I'd like to stress that the transition procedures I point out here
are not made up by me, but are really standard packaging practices that
are widely in use and have been implemented several times for other
packages. This might be the reason why nobody bothered too much about the
bugs you've found (, yet).
I have the impression that we confuse the other readers of this mailing
list with packaging mechanics and boring transition details. Can we
please have a statement from you that the procedure to implement symbol
versioning and the implementation idea of my patches are "approved" (as
M?ns asked for that) so that M?ns can continue with adapting my latest
patch for non-gnu linkers and commit it to SVN?
Anyway, regardless if we start both transitions for squeeze or not, the
first should be started ASAP. If I can be confident that this will be
done upstream, I'd like to apply this to the FFmpeg 0.5 package and
start the 1st transition.
Reinhard Tartler, KeyID 945348A4
More information about the ffmpeg-devel