As of 2.6.38 kernels and kernel headers, video4linux version 1 is no longer supported. Filing this bug against libv4l for lack of a single other bug to track packages it effects.
Steps to Reproduce:
USE="-video v4l2" emerge mediastreamer
emerge fails due to no videodev.h (v4l-1 support header)
successful build with no v4l1 support
As of 2.6.38 kernels and kernel headers, video4linux version 1 is no longer supported. [Possibly badly]Autotooled packages are finding headers and/or pkgconfig files provided by libv4l and failing to compile because they inherit a dep on videodev.h (header for old v4l support).
Moving /usr/lib64/libv4l1.so and /usr/lib64/pkgconfig/libv4l1.pc allow media-libs/mediastreamer to build, but then other packages fail (linphone with +video) cannot build.
Should bugs be filed on libv4l or against the packages that are finding its files (for being badly autotooled)? If on libv4l, should v4l not install the v1 files?
Please add B
I might add, currently
USE="-video v4l2" will do nothing of value with v4l2, as v4l2 dependencies are subject to the video use flag.
So one would expect it to build properly *with* USE="video v4l2" as well.
I'd suggest adding the v4l use flag then use-mask it out in the profiles, and then making the dependency of it depend on a kernel version old enough that it will work.
At least that way, by default v4l support will get dropped, but people who *really* need it can remove the use.mask and still have it available while a transition is made.
I've been experimenting some with the v4l-1 header libv4l provides, libv4l1-videodev.h ... if header checks were done for that file rather than linux/videodev.h, things may be satisfied with only minor changes. the package I've been using to test has been mediastreamer and doesn't look like it will take much to make it work with it. Others could maybe work the same.
libv4l uses the v4l2 kernel API. It provides a wrapper around that API to automatically perform hardware-specific pixel format conversions and image rotation. It allows software to be written for an "ideal spherical v4l2 device" without worrying about the strange hacks and workarounds that are needed by hundreds of random USB webcam models.
In addition, libv4l includes the libv4l1 convenience library, which provides user-level emulation of the v4l1 API, and allows older software that uses v4l1 API to access v4l2 devices.
If v4l1 in Gentoo will be deprecated, it may make sense to make the installation of libv4l1 be controlled by a USE flag. However, this flag should NOT be usemasked because
(a) libv4l1 does not use the kernel's v4l1 support in any way, and works perfectly well on modern kernels; and
(b) it provides a perfectly good way for random old and binary software to access modern video devices on any kernel.
Finally, any packages that assume "if libv4l1.pc exists, then videodev.h exists" are BROKEN and need to be fixed. They should instead use libv4l1-videodev.h, which (as you can guess from the filename) the actual header installed by libv4l.
I agree about the broken assumptions based on libv4l1.pc existence. About USE masking a "v4l1" flag, I can see that as a solution if upstream (or no-longer developed) software continues to reply on videodev.h, but for software handling things better, I don't think it should be needed. If packages can work with the emulation, even, I wouldn't agree with profile masking either.
v4l isn't something I've used much until the last couple weeks, which is convenient since I have a little time to dig in and look as well as use it at an example case to learn more about autotools.
How is this a bug? It's there exactly for the purpose to provide backward compability for a little longer.