[FFmpeg-devel] Round 2: Symbol versioning

[Michael Niedermayer]

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.


>  - Therefore, even with Michael's patch symbol versioning is necessary.

yes


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

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 at the expense of hundreads of
otherwise unneeded dependancies.

But at this point you have not introduced the new libavutil with new
ABI and new soname. 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
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.


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


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

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- 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/20091228/189215f4/attachment.pgp>