How should ambiguous package specifications be handled?

How should ambiguous package specifications be handled?

[Christopher Baines]

[-- 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 --]

Re: How should ambiguous package specifications be handled?

[Tobias Geerinckx-Rice]

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

Christopher,

Christopher Baines 写道：
> We've had one for a while (itstool 2.0.6), and another has 
> recently been
> introduced (sassc 3.6.1).

Thanks for noticing this!

The sassc variant being visible was definitely a mistake.  I added 
it as a local variable first and forgot to hide it after changing 
my mind.  This is now fixed.

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

That's a good idea at the very least.  I don't think such 
duplication is ever justified.

Kind regards,

T G-R

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

Re: How should ambiguous package specifications be handled?

[Ludovic Courtès]

Hello,

Tobias Geerinckx-Rice <me@tobias.gr> skribis:

> Christopher Baines 写道：

[...]

>> 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)?
>
> That's a good idea at the very least.  I don't think such duplication
> is ever justified.

I agree, a ‘lint’ warning would be nice.

However, I think that tools like Cuirass and the Data Service must be
able to cope with duplicates; they should not consider name+version as a
unique key for packages.

Ludo’.

Re: How should ambiguous package specifications be handled?

[Christopher Baines]

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


Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Christopher,
>
> Christopher Baines 写道：
>> We've had one for a while (itstool 2.0.6), and another has recently
>> been
>> introduced (sassc 3.6.1).
>
> Thanks for noticing this!
>
> The sassc variant being visible was definitely a mistake.  I added it
> as a local variable first and forgot to hide it after changing my
> mind.  This is now fixed.

Great, thanks for fixing the sassc issue :)

>> 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)?
>
> That's a good idea at the very least.  I don't think such duplication
> is ever justified.

Good good, I'll add it to my list of things to look at.

Thanks,

Chris

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