conflicts metadata should say <=

[rwfranks]

Transcribed verbatim from CPAN RT#93870, warts and all.

Fri Mar 14 18:00:37 2014 Kent Fredric - 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.

[rwfranks]

Sat Mar 15 04:43:51 2014 Karen Etheridge - Correspondence added

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

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'

[rwfranks]

Sat Mar 15 06:05:37 2014 Kent Fredric - 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
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