Re: Package API compatibility and guix package variable names

[Chris Marusich]

Andreas Enge <address@hidden> writes:

> The inputs of our packages are absolutely precise: They are given as scheme
> 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 time).
> So we have no way of saying, like in many other distributions, that the input
> is any "python >= 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 — 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 >= 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 “exact” dependencies such as

    Require: hello = 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

-- 
Chris

signature.asc
Description: PGP signature