Bug #93870 for DBI: conflicts metadata should say <=

Fri Mar 14 18:00:37 2014 KENTNL [...] cpan.org - Ticket created

Subject:

conflicts metadata should say <=

https://metacpan.org/source/TIMB/DBI-1.631/META.json#L35

+ CPAN::Meta::Check

Installed version (1.405) of SQL::Statement is in range '1.33'
Installed version (0.41) of DBD::CSV is in range '0.36'

Because presently, version ranges indicate ">=" if no qualifier is given, regardless of where that version is declared.

Not "<=" as one might expect.

Sat Mar 15 04:43:51 2014 ether [...] cpan.org - Correspondence added

On 2014-03-14 15:00:37, KENTNL wrote: Show quoted text

> https://metacpan.org/source/TIMB/DBI-1.631/META.json#L35 > > + CPAN::Meta::Check > > Installed version (1.405) of SQL::Statement is in range '1.33' > Installed version (0.41) of DBD::CSV is in range '0.36' > > Because presently, version ranges indicate ">=" if no qualifier is given, > regardless of where that version is declared. > > Not "<=" as one might expect.

No, for 'conflicts' fields, the version indicates the last version at which that module is problematic, so it is usually the case that a bare version number in conflicts is correct.

Sat Mar 15 04:43:52 2014 The RT System itself - Status changed from 'new' to 'open'

Sat Mar 15 06:05:37 2014 KENTNL [...] cpan.org - Correspondence added

Can you back that claim with documentation?

Also, either CPAN::Meta::Check is wrong, or the specification is wrong.

Which one is to be fixed?

And inline with this assertion: "the version indicates the last version at which that module is problematic"

Is that assertion applicable to , or indepdendent of, version ranges?

Obviously " <=5.00 == 6.00" is *not* indicating the "last version the module is probelmatic at".

Nor is ">=5.00", that is a clear indication that the release does not work at version 5.00, *or any successive release*

And in every other dependency atom,

"5.00" infers ">= 5.00"

And that is how it is implemented in the plumbing that makes CPAN::Meta::Check work.

To simplify, the mechanics are two parts:

conflicts: FOO

defines an arbitrary version range, and the left hand side does not change the semantics of the version range ( at least, if it does, or is supposed to, I can't find any documentation that backs that claim )

In version ranges, a number on its own is shorthand for ">= X.YY"

https://metacpan.org/pod/CPAN::Meta::Spec#Version-Ranges

There is nothing there about it being special cased to mean "<=" in conflicts.

And because the checking logic is simply:

1. Load module

2. end if module does not exist

3. end if module is NOT in the version range

4. if the module is in the version range, give failure

https://metacpan.org/source/LEONT/CPAN-Meta-Check-0.008/lib/CPAN/Meta/Check.pm#L29

Those two compounding effects means:

{ conflicts: "5.00" } == { conflicts: ">= 5.00" }

Just as

{ requires: "5.00" } == { requires: ">= 5.00" }

I know, my instinct was the other way around too. But its not how its implemented.

Subject:

irclog.txt

10:35:39 <@kentnl> q) https://metacpan.org/pod/CPAN::Meta::Check # what do people think this *should* do for verify_dependencies( .... , 'runtime','conflicts',.... ) 10:35:41 <+dipsy> [ CPAN::Meta::Check - Verify requirements in a CPAN::Meta object - metacpan.org ] 10:36:20 <@kentnl> what it presently appears to do is validate backwards, ie: sees "runtime.conflicts = { foo => 1.00 }" and then fail if foo > 1.00 10:36:54 <@mst> erm. => is not what you wanted there 10:37:21 <@mst> er. wait. for conflicts, isn't that right? 10:37:32 <@mst> 'foo: 1.00' means >1.00 10:37:47 <@mst> the parsing of a version requirement string doesn't change just because you're using it in 'conflicts' 10:38:10 <@kentnl> I'm not sure. I know it is everywhere else.... but not sure if this here is considered backwards or not: https://metacpan.org/source/TIMB/DBI-1.631/META.json#L35 10:38:13 <+dipsy> [ META.json - metacpan.org ] 10:38:50 <@mst> I believe that is incorrect and should be '<= 0.10' etc. 10:54:48 <@kentnl> That would be confusing, it would mean something like: conflicts : <= 5, == 6.65 # would be illogical 10:55:19 <@kentnl> unless you meant to say "Install <5 or == 6" . Where people probably meant to say "don't have these installed" 10:56:33 * kentnl gave a gloss over of a bunch of conflicts related things and they do seem to convey the feel that when you say 'conflicts : X' that you mean to say "dont have X" not "do have X" 10:57:54 <@mst> kentnl: er, no, that wouldn't mean that at all 10:57:59 <@mst> kentnl: what the fuck are you hallucinating? 10:58:20 <@mst> "<= 5, == 6.65" would work exactly how you expect 10:58:52 <@mst> the ONLY thing that is causing a problem here is that a *plain* version number as a version requirement is always interpreted as >= 10:58:58 <@mst> and as such, using them in conflicts is an error 10:59:04 <@mst> and as such, DBI's META info is bollocks 10:59:20 <@kentnl> oh. Right. Dur. 11:00:37 <@mst> I start to think that we should just fucking disallow them 11:00:50 <@mst> since they're almost never the right thing to do in a conflicts entry 11:07:35 < trs> they may be the right thing for legacy libs relying on other legacy libs. 11:08:18 < trs> but yeah, almost never. 11:11:54 <@mst> eh? 11:12:06 <@mst> ohhh, right 11:12:20 <@mst> yeah, I understand that, but I think that's a weird enough case that people should type out '>= 1.23' in that case 11:12:25 <@mst> the point is that the default doesn't DWIM 11:12:40 <@mst> this is the second conversation I've in here where I've ended up explaining it 11:12:56 <@mst> I'm not going to go back and check, because if it was with kentnl the first time I'm just going to get irritated ;) 11:13:11 < trs> heh 11:13:31 < trs> requiring explicit >= seems totally reasonable. 11:13:38 < trs> and disallowing bare versions all together. 11:13:47 <@kentnl> +1