How should ambiguous package specifications be handled?

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]

Hey,

I'm aware of duplicate packages as the Guix Data Service identifies
cases where there are two package definitions with the same name and
version [1].

We've had one for a while (itstool 2.0.6), and another has recently been
introduced (sassc 3.6.1).

Guix will tell you that something is up if you try and `guix build
itstool`, or `guix lint itstool`, as itstool could refer to either
package, as they both have the same version.

While the longer term fix for both these cases is to get rid of the
duplication once the issues that motivated the change are fixed, I
wanted to check what should and could be done about this general issue
before then.

Looking at the itstool case, there are similar duplicate packages for
yelp-tools (yelp-tools/fixed) and python-libxml2 (python-libxml2/fixed),
however building and linting them doesn't reveal any warnings. In the
yelp-tools/fixed case, the package is declared as hidden, and for
python-libxml2/fixed, the version is tweaked.

I guess the hidden approach is preferable if it's not expected that
anyone will want to explicitly install the package, and the version
change approach works better if you do want people to be able to install
the package.

Given there do seem to be ways of avoiding these ambiguous package
specifications, would it be helpful to have a lint warning that
identifies a package as being ambiguous (as it shares the name and
version with another package)?

Thanks,

Chris

1: search for "warning: ignoring duplicate package:"
http://data.guix.gnu.org/job/14282

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]