# from Michael G Schwern
# on Monday 23 July 2007 11:45 am:
>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.
It is a normalization.
package perl;
our $VERSION = $];
(or roughly so)
>> 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.
Debian has a great package management system which (sadly) is not
installed on most target non-debian machines. We don't usually have a
database available to determine which versions of which software are
installed, so the procedure for determining the availability and
version depends on the platform, the software, etc.
How would a system without a package manager determine the installed
version of perl? python? ruby? postgres? It would likely run some
command for each package, where "some command" means possibly applying
regexps to the output of `$foo --version`. Does the META.yml need to
contain those commands and regexps or do the tools need a-priori
knowledge of how to get version numbers for *every* possibly
dependency?
--Eric
--
hobgoblin n 1: (folklore) a small grotesque supernatural creature that
makes trouble for human beings
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
