Bug#504220: usage of Requires.private in *.pc files
Reinhard Tartler
siretart at tauware.de
Mon Nov 10 15:28:59 UTC 2008
The following message is a courtesy copy of an article
that has been posted to gmane.comp.video.ffmpeg.devel as well.
When generating the .pc files, ffmpeg currently places the following
libs into Requires.private: libraw1394, dirac, theora, vorbisenc.
I think this is wrong. Please let me explain why.
I've spoken to pkg-config upstream on irc about Libs.private
vs. Requires.private. The topic was if package building against
libavcodec would need to have the libtheora development packages (that
include both headers and the .pc file) installed:
15:46:55 < Mithrandir> siretart: you need to depend on the -dev
packages.
15:47:35 < siretart> Mithrandir: but isn't that insane? why do depending
packages need to care about whether libavcodec-dev links against
libtheora or not?
15:48:07 < Mithrandir> siretart: if it is in "Requires.private", then it
not only links with it, but also needs the headers from it.
15:48:21 < Mithrandir> like gtk exposes glib types in its headers.
15:48:39 < siretart> Mithrandir: libavcodec does not TTBOMK expose any
libtheora internals
15:48:41 < Mithrandir> if it just links with it without exposing any of
libtheora's types, using libs.private should be fine.
15:49:12 < siretart> okay. is there any documentation or any document I
could point upstream at to get that fixed?
15:49:38 < Mithrandir> once I get around to writing it. :-/
15:49:53 < siretart> may I quote this irc conversation?
15:53:44 < Mithrandir> sure.
Is that done on purpose, read: does ffmpeg really expose internals of
that libs to applications?
I believe that the following lines in ffmpeg are not correct:
enabled libdc1394 && append pkg_requires "libraw1394"
enabled libdirac && append pkg_requires "dirac"
enabled libtheora && append pkg_requires "theora"
enabled libvorbis && append pkg_requires "vorbisenc"
and should be replaced with something that places them into the
Libs.private instead of the Required.private field instead. But before
suggesting a patch implementing that, I wanted to ask you if you are
aware at all about the issue, and if avcodec would indeed expose
internals of the libs and all of this was done on purpose.
For full background, please read
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504220
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
More information about the pkg-multimedia-maintainers
mailing list