GNOME Bugzilla – Bug 620310
vpx plugin check headers in hardcodec location
Last modified: 2010-06-06 17:35:23 UTC
The configure.ac check does: AG_GST_CHECK_LIBHEADER(VPX, vpx, vpx_codec_version, , vpvpx/vpx_codec.h, while the opensuse packages (https://build.opensuse.org/package/show?package=libvpx&project=multimedia:libs) look like this: > rpm -ql libvpx-devel /usr/include/vp8.h /usr/include/vp8cx.h /usr/include/vp8dx.h /usr/include/vp8e.h /usr/include/vpx_codec.h /usr/include/vpx_codec_impl_bottom.h /usr/include/vpx_codec_impl_top.h /usr/include/vpx_decoder.h /usr/include/vpx_decoder_compat.h /usr/include/vpx_encoder.h /usr/include/vpx_image.h /usr/include/vpx_integer.h /usr/lib/libvpx.a Ideally libvpx-devel would come with a pkg-config file.
Filed an upstream bug for suse as well https://bugzilla.novell.com/show_bug.cgi?id=610773
This looks like either a WONTFIX or NOTGNOME to me tbh. Yes, upstream should provide a pkg-config .pc file. They hopefully will soon. In the meantime Novell and others should either package things the way debian/ubuntu/fedora have chosen to do or patch their gst-plugins-bad configure; dumping 12 vp* files into /usr/include just doesn't seem right.
When filing bugs against package bugtrackers, it should be made clear that the /usr/include/vpx/ directory location was a decision by the Fedora, Ubuntu and Debian packagers that we hoped others (in particular upstream once they support make install) would adopt. It's neither the packager's fault nor upstream's when the headers are in the "wrong" directory.
This was fixed a week+ ago in libvpx git. We'd check for an updated version in a .pc file, but...
To be clear, "fixed upstream" means that make install installs to ${prefix}/vpx/.
> It's neither the packager's fault nor upstream's > when the headers are in the "wrong" directory. For me the question is whether we as a project want to encourage consistent packaging of this new library across distros while we have a chance, or if we want to encourage everyone doing 'their own' thing by accommodating them. (Who cares whose "fault" it is..)
It's kinda important to me, because I'd like to avoid the haters. And you get a lot of haters when you're the #1 distro and just decide things. And a "please do what others do" sounds a lot better than "your package is broken".
Erm, libvpx didn't have a real "make install" rule with the last release and it was only added recently to their GIT. The "make install" that was there before was more a "make dist". I didn't decide the /usr/include/vpx location, in fact I've asked Google if that's what they intend to use in the future once they have a correct "make install".
Suse updated the package too. Everything fine now.