bug#43501: gst-plugins-bad cannot be built on linux-armhf, breaking qemu

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hello Mark!

Mark H Weaver <mhw@netris.org> writes:

> Earlier, I wrote:
>> Ever since 'spice-gtk' was added, it has included *every* gstreamer
>> plugin package in its 'propagated-inputs'.
>
> On my private branch, I removed 'gst-libav', 'gst-plugins-bad' and
> 'gst-plugins-ugly' from the propagated-inputs of 'spice-gtk'.
>
> diff --git a/gnu/packages/spice.scm b/gnu/packages/spice.scm
> index 4aff8dbf56..4b4c673a9d 100644
> --- a/gnu/packages/spice.scm
> +++ b/gnu/packages/spice.scm
> @@ -144,11 +144,8 @@ which allows users to view a desktop computing environment.")
>      (build-system gnu-build-system)
>      (propagated-inputs
>        `(("gstreamer" ,gstreamer)
> -        ("gst-libav" ,gst-libav)

I feel less strongly about this one, perhaps because its name doesn't
contain "bad" or "ugly" ;-).  Why should we remove it?

>          ("gst-plugins-base" ,gst-plugins-base)
>          ("gst-plugins-good" ,gst-plugins-good)
> -        ("gst-plugins-bad" ,gst-plugins-bad)
> -        ("gst-plugins-ugly" ,gst-plugins-ugly)
>          ("spice-protocol" ,spice-protocol)

I'd be in favor of not promoting plugins which are known to be of 1)
subpar quality (bad) or patent encumbered (ugly), by letting the users
install them if they choose, but not forcing those on them.

>          ;; These are required by the pkg-config files.
>
> I rebuilt my system and user profiles with this patch applied, and
> everything seems to work fine.  Moreover, I'm glad to report that
> 'gst-plugins-ugly' is no longer in my store.  (Sadly, 'gst-plugins-bad'
> still is, because our 'gnome' package depends on 'cheese' which depends
> on 'gst-plugins-bad', and last I checked that was unavoidable.)

That's unfortunate.

> I haven't tried using the 'spice' functionality specifically, but I
> suspect that any reduced "out-of-the-box" functionality could be
> regained by users simply installing those plugins as needed, along with
> gstreamer for its 'native-search-paths' field.

They wouldn't even need to install gstreamer itself as it is propagated
in the spice-gtk hunk shown above.

> What do you think?

I agree philosophically, but I feel we need more testing of the spice
part, to know what we're loosing, if we're loosing anything.  I'll try
rebuilding qemu with this patch and test gnome-boxes, which must make
use of spice-gtk.

>       Mark
>
> PS: Danny's idea is worth considering in its own right, but I think it's
>     orthogonal to this proposed change.

Seconded.

Maxim