[SCM] FFmpeg packaging branch, master, updated. upstream/0.svn20090119-38-g4098a63

Fabian Greffrath greffrath at leat.rub.de
Mon Jan 26 13:07:51 UTC 2009


Loïc Minier schrieb:
>  Just for the record, I tried it out to build ffmpeg-debian.git without
>  debian/shlibs.local and with manual ${binary:Version} interdependencies
>  and it works fine; e.g. after this change:

Thanks for trying this out!

>  Now there's a high number of libs in ffmpeg{-debian,}, so I guess
>  shlibs.local is easier in that we wont have to maintain
>  inter-dependencies ourselves.

Yes, it's tedious to keep the inter-dependencies up to date by hand 
for each library and -- if ffmpeg happens to add/remove/split 
libraries (as they did with e.g. libavdevice) -- it's error-prone. So 
this should be considered a hack.

>  Another thing which we could do to avois a debian/shlibs.local file is:
>      dh_makeshlibs -V<very-strict-inter-deps>
>      dh_shlibdeps
>      dh_makeshlibs -V<target-deps-for-other-packages>

This is a hack, too.

>  but it's almost as ugly as debian/shlibs.local.   :-/

this is the initial hack as suggested.

> One thing which we do in some GNOME packages are >= upstream-version,
>  << next-upstream-version typ eof deps; e.g. nautilus deps:
>     nautilus-data (>= 1:2.25), nautilus-data (<< 1:2.26)
>  I guess we could use some -99 revision or something similar to achieve
>  the same thing for each upstream version.

and this is another hack which introduces artificial dependencies.

Dear Friends, I believe we cannot avoid to introduce a 
more-or-less-ugly hack to achieve what we want. The question is: Which 
way shall we go now?


-- 
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax:     +49 (0)234 / 32-14227
E-Mail:  greffrath at leat.ruhr-uni-bochum.de



More information about the pkg-multimedia-maintainers mailing list