[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