Adam Kennedy wrote: > I'll just inject a note of caution here again though. Debian deals with > binary packages, CPAN deals with source packages.
A common misconception, as most people only interact with Debian binary packages. Debian also supplies source packages, of course they do--where else do the binaries come from? The same Debian control file (our META.yml equivalent) applies to both the binary and source package. There's a whole section in the policy manual about source packages. http://www.us.debian.org/doc/debian-policy/ch-source.html Where the fundamental difference lies between META.yml and Debian is that Debian controls the entire environment and the whole package release system is coordinated, where we don't even control the Perl installation and our package releases are uncoordinated. For example, Debian can coordinate the upgrade of several related packages all at once to avoid any mutual incompatibilities. We have a lot of trouble doing that. Something closer to what we face is fink and MacPorts. Like us, they are all packaging systems which live within an environment they don't control. They're also primarily source distributions. Unlike us, they can do coordinated releases. They also have only one environment to deal with (OS X) but do support multiple, somewhat incompatible, versions of OS X. Still, they have the same issues with external dependencies as we do. MacPorts is based on BSD ports. Like us, they're source only. They solve the external dependency problem largely by ignoring it. With the exception of basic build tools (like gcc) they ignore system installed programs and install their own. For example, rather than use the perl or ruby which ships with OS X they will install their own. Not an option. fink is based on Debian. Unlike Debian, and like us, they primarily ship source packages. They solve the external dependency problem with special virtual packages. These can detect the existence of already installed external programs [1] and make the package manager aware of them to resolve dependencies. Last time I looked, fink hard-wired their virtual packages into fink itself, the equivalent of hard-wiring them into CPAN.pm. They can get away with this because they have a single installer. We can't, and I don't think it's very robust anyway. [1] cups, java, openssl, perl sdk, ghostscript, tetex and xfree86 to name a few. -- Life is like a sewer - what you get out of it depends on what you put into it. - Tom Lehrer
