[bug#54744] Update gstreamer and its families to 1.20.1.

Here's a series of patches that updates gstreamer to 1.20.1.

`guix refresh gstreamer -l` shows that triggers 900+ rebuilds, I'm not
sure every packages depends on gstreamer is tested and worked well.
Currently only webkitgtk is tested.

Am Mittwoch, dem 06.04.2022 um 11:38 +0800 schrieb Zhu Zihao:
> 
> Here's a series of patches that updates gstreamer to 1.20.1.
> 
> `guix refresh gstreamer -l` shows that triggers 900+ rebuilds, I'm not
> sure every packages depends on gstreamer is tested and worked well. 
> Currently only webkitgtk is tested.
Indeed, gstreamer updates go to staging.

> * gnu/packages/gstreamer.scm (%gstreamer-version): New variable.
I don't think that's necessary or even beneficial.  Drop it.
Ditto for all the packages referencing it.

> * gnu/packages/gstreamer.scm (gst-plugins-good): Update to 1.20.1.
> [...]
> [propagated-inputs]: Remove unnecessary propagation.
Do gst-plugins-good really no longer depend on the base plugins?

> * gnu/packages/gstreamer.scm (gst-plugins-ugly): Update to 1.20.1.
> [...]
> [propagated-inputs]: Remove unnecessary propagation.
Idem.

> * gnu/packages/gstreamer.scm (gst-libav): Update to 1.20.1.
> [...]
> [propagated-inputs]: Remove unnecessary propagation.
Ibidem.

> (gst-plugins/selection): Remove because it's not useful in packaging
> and requires extra maintenance.
> * gnu/packages/video.scm (pitivi)[inputs]: Use gst-plugins-bad.
Packages that only require some bad plugins and can exactly state which
should not be forced to pull in all of them.  The bad plugins are
explicitly named bad, because they're bad.  Enabling any of them beyond
necessity should be an active choice of the user.

> * gnu/packages/webkit.scm (webkitgtk):
> [inputs]: Add gst-plugins-bad. It provides gstreamer-parsecodec.
My, what a perfect use case for gst-plugins/selection that would be. 
Note, that gratuitous media codecs are an additional attack surface.

Cheers

Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> writes:
>> * gnu/packages/gstreamer.scm (%gstreamer-version): New variable.
> I don't think that's necessary or even beneficial.  Drop it.
> Ditto for all the packages referencing it.

Good. From my view this can ensure packager to update every package of
gstreamer, not only a part of them. Gstreamer now use a monorepo for all
its components, they'll also have regular release cycle for all
components.

>> * gnu/packages/gstreamer.scm (gst-plugins-good): Update to 1.20.1.
>> [...]
>> [propagated-inputs]: Remove unnecessary propagation.
> Do gst-plugins-good really no longer depend on the base plugins?
>
>> * gnu/packages/gstreamer.scm (gst-plugins-ugly): Update to 1.20.1.
>> [...]
>> [propagated-inputs]: Remove unnecessary propagation.
> Idem.
>
>> * gnu/packages/gstreamer.scm (gst-libav): Update to 1.20.1.
>> [...]
>> [propagated-inputs]: Remove unnecessary propagation.
> Ibidem.

I checked the ugly and good and gst-libav, they do rely on
gst-plugins-base, but no propagation needed. I don't find a reason that
they really requires propagation, because their content just a so file.
Gstreamer in Nixpkgs also don't have propagations for above packages.

For necessary propgations like gst-plugins-bad(header or gi), I've added
some comments.

>> (gst-plugins/selection): Remove because it's not useful in packaging
>> and requires extra maintenance.
>> * gnu/packages/video.scm (pitivi)[inputs]: Use gst-plugins-bad.
> Packages that only require some bad plugins and can exactly state which
> should not be forced to pull in all of them.  The bad plugins are
> explicitly named bad, because they're bad.  Enabling any of them beyond
> necessity should be an active choice of the user.
>
>> * gnu/packages/webkit.scm (webkitgtk):
>> [inputs]: Add gst-plugins-bad. It provides gstreamer-parsecodec.
> My, what a perfect use case for gst-plugins/selection that would be. 
> Note, that gratuitous media codecs are an additional attack surface.
>
> Cheers

I'll investigate into it.

Currently I only see pitivi use gst-plugins/selection. Many package use
gst-plugins-bad directly. 

BTW, how to maintain changes for a long patches series like this in the
review phase? It's quite annoying when I make some minor changes but I
have to re-sent all patches to the mail list.

Am Mittwoch, dem 06.04.2022 um 17:16 +0800 schrieb Zhu Zihao:
> 
> Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> writes:
> > > * gnu/packages/gstreamer.scm (%gstreamer-version): New variable.
> > I don't think that's necessary or even beneficial.  Drop it.
> > Ditto for all the packages referencing it.
> 
> Good. From my view this can ensure packager to update every package
> of gstreamer, not only a part of them. Gstreamer now use a monorepo
> for all its components, they'll also have regular release cycle for
> all components.
Can't really say that the monorepo is a good idea nor condemn it
without knowing the motivations behind, but let's hope that things
still build in isolation.  As for updating, the new variable does more
harm than good.  It forces every build to break when actually the build
would have been sane.  IMHO you should instead leave compatibility
breaking changes to upstream.

> > > * gnu/packages/gstreamer.scm (gst-plugins-good): Update to
> > > 1.20.1.
> > > [...]
> > > [propagated-inputs]: Remove unnecessary propagation.
> > Do gst-plugins-good really no longer depend on the base plugins?
> > 
> > > * gnu/packages/gstreamer.scm (gst-plugins-ugly): Update to
> > > 1.20.1.
> > > [...]
> > > [propagated-inputs]: Remove unnecessary propagation.
> > Idem.
> > 
> > > * gnu/packages/gstreamer.scm (gst-libav): Update to 1.20.1.
> > > [...]
> > > [propagated-inputs]: Remove unnecessary propagation.
> > Ibidem.
> 
> I checked the ugly and good and gst-libav, they do rely on
> gst-plugins-base, but no propagation needed. I don't find a reason
> that they really requires propagation, because their content just a
> so file.
> Gstreamer in Nixpkgs also don't have propagations for above packages.
I personally found that missing these GstElements at runtime can screw
you up.  If that is no longer the case, then fair enough, but you need
to prove that by launching a gst pipeline using a plugin from e.g. gst-
plugins-good without having gst-plugins-base in your GST paths.

> For necessary propgations like gst-plugins-bad(header or gi), I've
> added some comments.
That is always welcome.

> > 
> > > (gst-plugins/selection): Remove because it's not useful in
> > > packaging and requires extra maintenance.
> > > * gnu/packages/video.scm (pitivi)[inputs]: Use gst-plugins-bad.
> > Packages that only require some bad plugins and can exactly state
> > which should not be forced to pull in all of them.  The bad plugins
> > are explicitly named bad, because they're bad.  Enabling any of
> > them beyond necessity should be an active choice of the user.
> > 
> > 
> > > * gnu/packages/webkit.scm (webkitgtk):
> > > [inputs]: Add gst-plugins-bad. It provides gstreamer-parsecodec.
> > My, what a perfect use case for gst-plugins/selection that would
> > be.  Note, that gratuitous media codecs are an additional attack
> > surface.
> > 
> > Cheers
> 
> I'll investigate into it.
> 
> Currently I only see pitivi use gst-plugins/selection.  Many packages
> use gst-plugins-bad directly. 
Whether to use gst-plugins-bad or a selection of it is a per-package
decision.  It depends on whether upstream communicates clearly which
plugins they need or whether you'd have to pull hairs out of their
noses to do so.  In the latter case, it's likelier that they include it
just because they can and will introduce more dependencies on it as
time marches forward.
For most packages not using it, there might however just be a
historical reason – gst-plugins/selection has not existed for that
long.  If you feel it is underused, you might want to search for
packages that (like Pitivi) provide a clear description of what they
need.

> BTW, how to maintain changes for a long patches series like this in
> the review phase? It's quite annoying when I make some minor changes
> but I have to re-sent all patches to the mail list.
Ideally, you would send them one by one using `git send-email'.  Then
you can send a v2 for an individual patch.  Note that excessive use of
minor changes might however annoy both reviewers and infrastructure (I
hear there's a patchwork instance somewhere actually building these
packages).  In my opinion it would be wiser to let it sit for a while,
collect opinions, and then formulate a v2 with all of those in mind.

Note that in your case, v2 should also be sent to staging, i.e. [PATCH
staging v2].

Cheers

Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> writes:

>> I checked the ugly and good and gst-libav, they do rely on
>> gst-plugins-base, but no propagation needed. I don't find a reason
>> that they really requires propagation, because their content just a
>> so file.
>> Gstreamer in Nixpkgs also don't have propagations for above packages.
> I personally found that missing these GstElements at runtime can screw
> you up.  If that is no longer the case, then fair enough, but you need
> to prove that by launching a gst pipeline using a plugin from e.g. gst-
> plugins-good without having gst-plugins-base in your GST paths.

Re-check the source code of good,ugly,gst-libav. It looks that some good
plugins will use gst_element_factory_make to create element in base,
It's reasonable for gst-plugins-good to propagates
gst-plugins-base(propagation of gstreamer is not neeeded, I think)

But for ugly and gst-libav. I don't see such code in their source code.
So It's better to remove their propagated-inputs.

Am Mittwoch, dem 06.04.2022 um 23:34 +0800 schrieb Zhu Zihao:
> Re-check the source code of good,ugly,gst-libav. It looks that some
> good plugins will use gst_element_factory_make to create element in
> base, It's reasonable for gst-plugins-good to propagates
> gst-plugins-base(propagation of gstreamer is not neeeded, I think)
The explicit propagation of gstreamer from any of the plugin paths is
so that GST_PLUGIN_SYSTEM_PATH is set.  However, it might be a little
too restrictive – it does prohibit combination of any of the plugins
with a slightly differently built gstreamer.

> But for ugly and gst-libav. I don't see such code in their source
> code.  So It's better to remove their propagated-inputs.
Static analysis is not enough here, you need integration tests.