Am Mittwoch, dem 06.04.2022 um 17:16 +0800 schrieb Zhu Zihao: > > Liliana Marie Prikler 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