[FFmpeg-devel] Round 2: Symbol versioning

[Michael Niedermayer]

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


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

libavutil50 (installed)

favorite_app depends on libavutil49
favorite_app depends on libfoo0

libfoo0 1.0 depends on libbar0
libbar0 uses versioning
libbar0 1.0  depends on libavutil49
libbar1 2.0  (installed) depends on libavutil50
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 ;)


> 
> Okay, you can now argue that this again works around "bugs" in ld.
> That's right then, but I don't really see a problem with that either;
> apt handles that just fine.
> 
> For the same reason, bug #3 cannot occur in practice either.
> 

> Still, I of course understand that the issues you've identified are real
> and should be addressed upstream.

yes


[...]

> >> > 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?
> >
> > I wont deal with drepper :)
> > What i will do is fix issues with my patch people notify me off
> 
> I'll make a note and will consider forwarding it upstream. Currently I'm
> still a bit unsure about the side effects your patch can cause and I
> need to experiment a bit more with it before I can proceed with that.

thank you

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- 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/5f5a4e53/attachment.pgp>