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

[Liliana Marie Prikler]

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