How to update packages where backwards compatibility would break? (case in point: `mitscheme`)


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).

The mit-scheme/default.nix expression checks for systems -i386 and -x86-64, fetching the corresponding tarballs, and falls back to the portable C source tarball in any other case. This is straightforward, but in the latest 10.1 release the portable C version and binaries for Windows systems are not included.

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?

  version = "9.2";
  bootstrapFromC = ! (stdenv.isi686 || stdenv.isx86_64);

  arch = if      stdenv.isi686   then "-i386"
         else if stdenv.isx86_64 then "-x86-64"
         else                         "";
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";


While I do see windows as a supported platform

(import <nixpkgs>{})
[ "i686-cygwin" "x86_64-cygwin" "x86_64-windows" "i686-windows" ]

in 9.2 version of nixpkgs, the supported platforms are only gnu, linux, and freebsd. Hence, probably you can choose to not worry about Windows.

I do see a file at the end of listing here that seems to be a “platform independent” source tar. Is it not?

I am interested in hearing an answer to this question though, how would a maintainer test his changes on all the platforms?

1 Like

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.

Edit: Just read the MIT/GNU Scheme - GNU Project - Free Software Foundation page more carefully, and I think this is the part I missed the first time:

Stable release 10.1.10
File Arch Instructions Notes
Unix binary i386 unix installation
Unix binary x86-64 unix installation
macOS binary x86-64 Compiled on macOS 10.14.
Portable SVM (any) unix installation For use on any 64-bit unix system.
Source (.tar.gz) For unix systems; uses linefeeds as line delimiters.
Change log
MD5 checksums

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.

1 Like

Thanks @ElvishJerricco and @SRGOM! I’ll just open a pull request then, and we’ll see what happens.