perl5-dbi
conflicts metadata should say <=
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.
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'
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:
-
Load module
-
end if module does not exist
-
end if module is NOT in the version range
-
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