Please add your example to the commit message.

What is the difference between makeExtensible and makeScope (used for example in gnome3 attrset)?

AFAIK, newScope defines a new callPackage function that allows (in this case) any of the packages in gst_all_1 to automatically be passed to derivation functions. This allowed me to remove all the inherit gst-plugins-base; lines, and prevents errors like forgetting to pass the correct version of gstreamer.

makeExtensible adds the extend function, which allows packages in the attrset to be overridden. For example, previously you could have tried to override a package using something like this (in an overlay):

gst_all_1 = super.gst_all_1 // {
  gst-plugins-base = super.gst_all_1.gst-plugins-base.override (old: {
    enableWayland = false;
  });
};

In this case, gst_all_1.gst-plugins-base would refer to the overridden package, but gst_all_1.gst-plugins-good would still depend on the original gst-plugins-base package.

Now, the override could be done like this:

gst_all_1 = super.gst_all_1.extend (gstSelf: gstSuper: {
  gst-plugins-base = gstSuper.gst-plugins-base.override (old: {
    enableWayland = false;
  });
});

gst-plugins-good will now correctly be built with the overridden version of gst-plugins-base.

I based my implementation off of linuxPackagesFor.

@lopsided98

I guess this needs adaptations to work with this? (see eval)
Possibly others as well.

That problem should be fixed now. That was caused by my attempt to use callPackages instead of callPackage, which creates its own (int this case, incorrect) override function for each package.

I really would like someone knowledgeable in this area of nixpkgs to look at this PR. There are lots of package sets that follow a similar pattern to gstreamer, and very few provide an easy way to extend them in an overlay. Some of the larger packages sets such as perl and python packages use their own adhoc methods to allow overrides. python has the packageOverrides argument, while perlPackages has the overrides argument which both have different semantics. Even Python's packageOverrides does not work well in overlays.

The more I think about it, the more I think we need a more standardized way to override/extend nested package sets.

Alternative, more generic solution in #54266:

$ code='with import ./. { overlays = [
    (self: super: {
        _merge_gst_all_1 = true;
        gst_all_1.gst-plugins-bad = super.gst_all_1.gst-plugins-bad.overrideAttrs (old: rec {
            buildInputs = old.buildInputs ++ [ self.rtmpdump ];
        });
    })
]; }'

$ nix-build -E "$code; arravis" # <-- will rebuild arravis with our overriden gst-plugins-bad

The _merge_gst_all_1 = true; can also be specified in Nixpkgs, so user overlays will treat gst_all_1 as a mergeable attrset.

Reading through the related PRs, it seems to me that this PR shouldn't be merged without a standard extension system such as #51213.