Eric Wilhelm wrote: > # from Michael G Schwern > # on Monday 23 July 2007 12:22 am: > >> That part of the spec is currently written in a contradictory and >> implicit manner, the definition of "requires", as written, is very >> clear that the keys are Perl modules, but that's a simple thing to >> fix in the spec. I don't like the idea of the "requires" keys having >> special cases because I don't like special cases. > > Well, isn't the issue simply that `perl -Mperl -e 'warn perl->VERSION'` > doesn't work? There is already a perl-X.X.X.tar.gz on CPAN. There is > also a `perldoc -l perl`.
It would be very clever to release perl.pm and have it assign itself a $VERSION to match the perl version, but now this is a hack to support a hack. >> I'm not going to >> block "perl" as a special one, but META.yml is missing a way to >> specify general external dependencies. Compilers, web servers, mail >> servers, C libraries, etc... its a thorny problem and one that's >> been bandied about in the past. > > I think the conclusion usually comes out at leaving that to the > turing-complete configuration code. Basically, 'perl5' is a > configure_requires item (of sorts) but beyond that, the particulars are > checked by the Makefile.PL or Build.PL code. There's a pragmatic subset which can be dealt with. Once again, look to Debian. They've defined a number of virtual "provides" tags. For example, exim provides a "mail-transport-agent". mutt can then depend on a "mail-transport-agent". Its up to the toolchain to figure out if that dependency has been resolved.
