Overrides/overlays silently dropped by multiversion packaging

I apply some custom patches to wlroots in an overlay. During some rebase over the past few months these came to be silently ignored by nixpkgs because wlroots was split into wlroots and wlroots_0_16, and the primary downstream user (swaywm) was using wlroots_0_16.

This caused me some not inconsiderable pain.

Is there some obvious way to prevent silent failures like this from happening again?

If not, we should consider some kind of policy that would make it possible to prevent this kind of silent failure. For example some way of knowing which top-level attributes are merely variations on a single package (so a patch can be applied to all such variants).

Thanks,

not that I know off.

Everything with an underscore is just a versioned variant. Maybe we should do aliases for them all the time.
Applying overlays to all variants does not work and we have no way to know which attributes belong together from code.

1 Like

Well, actually, it could – you simply have to write a more general overlay that inspects the .version attribute. Of course it might have to fail when it encounters an unknown version, but that’s the goal – to fail with an error rather than silently dropping the overlay.

That’s unfortunate. Perhaps such a way should be created.

For now I’m reconstructing this knowledge from pnames by overriding stdenv.mkDerivation, but it’s not ideal. In particular it isn’t composable – it only works because there are no “downstream users” of my overlay (currently!).

Wouldn’t that mean we need to itterate over every package check if the attr matches and then compare the version number? Such a function would be terrible slow and I don’t know a smarter way to do this.

Hosted by Flying Circus.