[FFmpeg-devel] Round 2: Symbol versioning

Michael Niedermayer michaelni
Thu Dec 31 18:39:28 CET 2009

On Thu, Dec 31, 2009 at 10:33:45AM +0100, Reinhard Tartler wrote:
> 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.

Yes but thats still what i said:
" Well, if your chain of reasoning is that simply waiting long enough will
  make the conflicts likeliness aproach zero, ..."
Its from a somewhat different perspective but still the issue is there, 
someone can have an older package around
Note iam not saying that i think doing the thing in a more disruptive way
is worth it, rather that what you plan to do is not free of the possibility
of users breaking their system. While OTOH with a fixed linker there is no
possibility of users breaking their system even without all the renaming
and shlib deps

> >> 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 [1]. 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:
> > Example
> > 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
> finished.
> (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.

you assume users do upgrade every package on their system at the same
time. Or otherwise by magic assume this combination of packages wont
be installed on anyones system

> > 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).

Its the proof of optimality and correctness by tradition
This reminds me a little of some text about findinging the maximum of some
non trivial function.
That text used some real example from the author where some chemists wanted
to find the ph value at which the yield of some process was maximized with
a minium of time & experimentation ...
They where quite outraged when told to start the optimization with a test
in acidic and basic ph, as noone run the process in an basic environment
it seemed a waste of time to them to try that, but they did anyway.
Well the funny thing is their yield was higher at basic ph than the
acidic everyone was using.

> 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?

I already said that iam ok with adding versioning, i think your patches
are ok but i need to actually look at them

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091231/a299640a/attachment.pgp>

More information about the ffmpeg-devel mailing list