From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: Package API compatibility and guix package variable names Date: Wed, 27 Jul 2016 23:04:22 -0700 Message-ID: <878twm8fix.fsf@gmail.com> References: <20160719205719.20769-1-rekado@elephly.net> <87y44wdr1f.fsf@elephly.net> <20160727175431.35fc6326@scratchpost.org> <20160727161918.GA5300@solar> <20160727230615.33d2adc3@scratchpost.org> <20160727213302.GA9807@solar> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSeQo-0001EX-O1 for guix-devel@gnu.org; Thu, 28 Jul 2016 02:04:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bSeQn-0007F6-GR for guix-devel@gnu.org; Thu, 28 Jul 2016 02:04:30 -0400 Received: from mail-pa0-x232.google.com ([2607:f8b0:400e:c03::232]:34661) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSeQn-0007Ew-5C for guix-devel@gnu.org; Thu, 28 Jul 2016 02:04:29 -0400 Received: by mail-pa0-x232.google.com with SMTP id fi15so17696366pac.1 for ; Wed, 27 Jul 2016 23:04:29 -0700 (PDT) In-Reply-To: <20160727213302.GA9807@solar> (Andreas Enge's message of "Wed, 27 Jul 2016 23:33:02 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Andreas Enge Cc: guix-devel --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Andreas Enge writes: > The inputs of our packages are absolutely precise: They are given as sche= me > variables (which are, in a sense, a moving target, since their content > changes over time; but they are completely fixed at any given point in ti= me). > So we have no way of saying, like in many other distributions, that the i= nput > is any "python >=3D 2 and < 3"; in fact, we are always saying "use exactly > this Python, with this source, build system, inputs, etc.". For this reason, the exact structure of the name doesn't seem too important. My understanding is that Nix and Guix both avoid "nominal" dependency specifications specifically it's unreliable. The first few pages of Eelco Dolstra's Nix thesis [1] discuss the pitfalls of "nominal" dependency specification: "Related to the inability to validate dependency specifications is the fact that dependencies tend to be inexact. Above, xhello required that a component named hello is present =E2=80=94 but it makes no requirements on = the actual properties or interfaces of that component. That is, the dependency specification is nominal (determined by name only), not by contract (requiring that the dependency has certain properties). So any component named hello satisfies the dependency. Actually, we can require specific versions of the dependency: Requires: hello >=3D 1.0 which excludes version 1.0. However, such version specifications involve a high degree of wishful thinking, since we can never in general rely on the fact that any version in an open range works. For instance, there is no way to know whether future release 1.3.1 of hello will be backwards compatible. Even =E2=80=9Cexact=E2=80=9D dependencies such as Require: hello =3D 1.0 are unsafe, because this is still a nominal dependency: we can conceive of any number of component instances with name hello and version number 1.0 that behave completely differently. In fact, this is a real problem: Linux distributions from different vendors can easily have components with equal names (e.g., glibc-2.3.5) that actually have vendor-specific patches applied, have been built with specific options, compilers, or ABI options, and so on." [1] https://nixos.org/%7Eeelco/pubs/phd-thesis.pdf =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXmaBoAAoJEN1AmhXYIkad8t8QAMSeNP/tee8tb6nvgs0hxGiF bRb4/3pY2KjI8LJ6k+OMQXpAD1BO7SNbZiyBVqnOn+4dTjJ+EyjD9M/mO8HUl+Jo JBlH+L29uWwyIrGDx+n6NzvYDl2O5lJp05bHUiwmGbZ/fixv1TQrAz7foLxibuCs ydhRXFerv+CjdgY2SLMrEp9uiyxecoH83vZahHjhVwuXq3QOaD4nOK2Gxgo93ShH ze1Iy8H6ryNfkEEFVlyNlebNv2ipoZjw+NXHbnaMVOS4XrWaUAH2ypScOW01icej u0LLfzfdakbX6kpDoNHwBs5wQ8qoEgOxuHhufl/hdqPUy79Xkh1/Ia78lGCf58pb MF4k5cVsq/fHcdOfXpV7I6lSK5TgHvSi7l7dYQa/zxc3vUfrDZjFlRHzR6yI+USI HHgw4JkVHTn4JfPElsmYKMUv4qy+Ol5KQfDu3qdX+RF4LGwz15teX6XmfvUj4jqW KQeaH6fPpCrFqdTOxo8g6hAi9IIPXfK0GdZNJ2wjS0Ha3jw+IbhkHHUkL7bqcdzP 77hEImhTTtVtmyZYA6F6nE99U/32ar4Q+5AurQUTdEVu4y7BmYs8xNn32Gs5XCVp IMM+BdUuwA0VHnBzduVd1U4F7a7yHNCRdbGcXu7agovqftFOXQFG2ZI+gj3xId27 m3hONXASZzbnsneLArgJ =OklK -----END PGP SIGNATURE----- --=-=-=--