Re: Rebuilding a package after removing a build step

[Konrad Hinsen <konrad.hinsen@fastmail.net>]

Hi Kaelyn,

> Whether it does or doesn't depends on the versions of the duplicate
> packages in question. If both packages have the same version, then the
> command line tools will warn about the ambiguous package
> specification. If the version numbers are different, then the tools
> will quietly choose the "newer" version (the larger version number).

My case was in neither of these well-defined situations. I had different
version number strings without an obvious order relation between them.
Not obvious to me at least. Here is an example (edited for focus):

  $ guix show -L . sbcl-websocket-driver
  name: sbcl-websocket-driver
  version: 0.2.0-0.df94496
  location: gnu/packages/lisp-xyz.scm:30847:4

  name: sbcl-websocket-driver
  version: 0.2.0-0.17ba553
  location: ./kh/packages/lisp.scm:53:4

  $ guix build -L . sbcl-websocket-driver
  /gnu/store/nd9ajz9ni395792f03ggf3jprf44cgz2-sbcl-websocket-driver-0.2.0-0.df94496

There are two definitions for sbcl-websocket-driver, differing only in
the commit id. How did "guix build" choose the first one? The second one
is newer, but figuring this out requires checking out the repository
and analyzing its DAG. It looks like Guix picked the larger one by
alphanumeric order, which is not a reasonable choice in a development
context.

Cheers,
  Konrad.