Eric Wilhelm wrote: > # 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)
Its an interesting trick. I'm sure I can think of a few ways it will go horribly awry. One is getting installed into a Perl library directory shared between multiple perls. We might be able to avoid that by tricking the installer into thinking its architecture specific. These sorts of problems are why I worry about layering a hack on a hack. >>> 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? The beauty of meta-data is that its declarative. It says what, not how. The individual system using the META.yml figures out the how. The meta-data says "I need Python version 2.1" and the installer goes and figures that out. This is not to say we can't also write the installer for each distribution, just that they are wholly separate concerns. The CPAN shells can each have stuff to work with dpkg or rpm or fink or ports or whatever and the user can select them. We can declare the meta-data now without worrying about the implementation. Other people might even implement it for us. I'm sure the cpan2rpm and dpkg-perl folks will be happy.
