[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

How should ambiguous package specifications be handled?

From: Christopher Baines
Subject: How should ambiguous package specifications be handled?
Date: Thu, 23 Jan 2020 08:03:34 +0000
User-agent: mu4e 1.2.0; emacs 26.3


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



1: search for "warning: ignoring duplicate package:"

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]