Started working on my first Nixpkgs contribution to update the mit-scheme-9.2 package because version 9.2 came out in 2014, but the latest stable release is 10.1.10 from last Fall (8/2019).
Simply updating version and the sha256 checksum (and removing the portable C else clauses) in the original source below will result in successful builds but this new expression will break previous assumptions regarding this package. (Or will it?)
Should I just leave this alone (and use the updated expression on my local machines), or is there a canonical way forward for breaking changes like this?
let
version = "9.2";
bootstrapFromC = ! (stdenv.isi686 || stdenv.isx86_64);
arch = if stdenv.isi686 then "-i386"
else if stdenv.isx86_64 then "-x86-64"
else "";
in
stdenv.mkDerivation {
name = if enableX11 then "mit-scheme-x11-${version}" else "mit-scheme-${version}";
# MIT/GNU Scheme is not bootstrappable, so it's recommended to compile from
# the platform-specific tarballs, which contain pre-built binaries. It
# leads to more efficient code than when building the tarball that contains
# generated C code instead of those binaries.
src =
if stdenv.isi686
then fetchurl {
url = "mirror://gnu/mit-scheme/stable.pkg/${version}/mit-scheme-${version}-i386.tar.gz";
sha256 = "1fmlpnhf5a75db93phajh4ysbdgrgl72v45lk3kznriprl0a7jc6";
} else if stdenv.isx86_64
then fetchurl {
url = "mirror://gnu/mit-scheme/stable.pkg/${version}/mit-scheme-${version}-x86-64.tar.gz";
sha256 = "1skzxxhr0iq96bf0j5m7mvf3i4sppfyfa6gpqn34mwgkw1fx8274";
} else fetchurl {
url = "mirror://gnu/mit-scheme/stable.pkg/${version}/mit-scheme-c-${version}.tar.gz";
sha256 = "0w5ib5vsidihb4hb6fma3sp596ykr8izagm57axvgd6lqzwicsjg";
};
Thanks, it shows I’ve been out of touch with Nix for a while.
I do see a file at the end of listing here that seems to be a “platform independent” source tar. Is it not?
Yes, and I forgot to mention this in the initial post, and here’s my confusion: Previous releases also have the “platform independent” tar file and a C source archive. The default.nix points to the latter, but maybe for historical reasons? Couldn’t find what the exact differences are (or I just missed), but maybe it is ok just use that as a fallback.
Note that you cannot build a working system from the source unless you have a working MIT/GNU Scheme compiler to do the compilation. (This doesn’t apply to the portable C source, which requires only a C compiler.) This means that if the above binaries don’t work on your system, it is pointless to try building a custom set of binaries from the source code.
… and because a portable C source is not included, there’s not much that can be done.
The Nix Packages collection (Nixpkgs) is a set of over 40 000 packages for the Nix package manager, released under a permissive MIT/X11 license. It supports the following platforms (though not all packages work on all platforms):
GNU/Linux on 32-bit (i686-linux)
GNU/Linux on 64-bit x86 (x86_64-linux)
Apple macOS (x86_64-darwin) (macOS v10.12+)
Beta support for GNU/Linux on ARM’s aarch64 (aarch64-linux)
So I think you’re ok dropping the C tarball entirely. This is the package’s fault, not nixpkgs’. That it won’t work on ARM is probably fine since that’s considered beta for nixpkgs.