nix versioning policy for newer features

[kinetiknz]

What is nix's versioning policy for adding newer platform features? Is there a minimum OS version that nix and applications built using it are expected to run on?

In a project currently being integrated into Firefox, we're trying to use nix and have run into an issue where the minimum glibc version we must support is 2.12 but nix includes setns which is only available in 2.14 onwards. From a quick scan through glibc's abilist, that's currently the only symbol from a glibc newer than 2.12, so there are two questions:

1. Would you accept a PR that optionally disables newer features to allow compatibility with older systems? This seems trivial to solve for the case described above, but I'm not sure what a solution would look like that handled multiple OS or glibc versions over time.
2. (repeating the opening question) What's the long term plan for handling versioning of newer OS features in nix?

While my example is specific to glibc, this question generally applies to other platforms. A theoretical example might be the use of readlinkat which was only made available in OS X 10.10, making use of nix on older OS X versions impossible. I understand that older OS X versions tend to become unsupported fairly quickly, so this specific example isn't ideal but you can imagine this problem may reoccur if new features are added to 10.13 or later and then included in nix.

[Susurrus]

This is an excellent question! Right now we've been deferring on answering these questions because the Rust community hasn't quite figured out how to handle this. I've contributed both to libc and winapi-rs which both punt on the issue and say they support basically the newest things they can run in CI.

I've also contributed to gtk-rs, which use gtk versions as feature flags and that seems to work alright since they have them cascaded, so if you do features = 3.26, you'll get everything in 3.26 or below. I'd think a similar feature list for us could be doable where you can specify features for the different functionality. We don't need it for musl, but for everything else it'd be straight-forward I think. Like in your case we can have a glibc = 2.12 feature that would make sure you don't have issues with newer features causing compilation issues.

That all being said, I do think we need to start applying developer time to this. Personally, I think it'd be pretty awesome to have Firefox as a consumer of nix. But the counterpoint to that is that nix doesn't provide too much of a wrapper around the bare libc, so it might make sense to not even tackle this quite yet for Firefox's and just use straight libc.

[asomers]

I agree that feature flags are the best way to handle this, unless Rust evolves more detailed platform descriptions. A major unsolved question is how to handle C ABI changes between versions. For example, statfs and many other functions change their signatures in FreeBSD 12. It is probably possible to use ELF symbol versioning to select which ABI to use, but I haven't seen anybody do it yet.

[Susurrus]

@asomers That conversation is happening rust-lang/libc#721

[semarie]

@asomers the target-extension proposed RFC has this goal: tracking breaking changes at OS level.

[Susurrus]

@semarie bad link

[semarie]

@Susurrus thanks. I updated the comment.

[Susurrus]

Been a while on this, @kinetiknz any updates on your end for your min version requirements?