On Fri, May 29, 2009 at 01:04:28AM +0200, Daniel Carrera wrote: > Hi Alex, > > I hve comments. > > Alex Elsayed wrote: >> While lurking in IRC, I've seen several discussions of what CPAN 6 >> should look like. Honestly, wayland76++'s idea for packaging seems the >> best to me. Most of the suggestions so far, especially those based on >> alien, apt, yum, or other existing package managers have a few major >> problems: >> >> * Alien only converts between a few package formats >> * All of these suggestions are _heavily_ biased towards binary distributions >> * These suggestions make automatic packaging for new distros extremely >> difficult, because they require major changes to multiple projects > > * We were mainly looking at Alien as a source of Perl code we could borrow. > * The point of wayland76's proposal was to use the local package > manager. Whether the local package manager is geared toward binary > distributions is a separate issue.
I support the notion of distributing binaries because nobody's gonna want to chew up their phone's battery doing unnecessary compiles. The ecology of computing devices is different from ten years ago. > At first I liked wayland76's proposal, but now I have a new concern: > Most package managers are not designed to hold multiple versions of the > same package. As indicated in S11, it is important that a computer can > hold multiple versions of the same package. I fear that using the native > package manager will make this difficult. Most of these package managers have ways of running an installation script at the end, so we could perhaps think of this as downloading an installer rather than the actual software, and the new version of the installer contains or has access to all the versions it knows should be installed, and interacts with the official Perl library installer to install them. >> * Separate the metadata from the package >> * If the metadata is in the source distribution, have CPAN 6 >> extract it, and put it in a separate tree of just metadata >> * This enables simple fetching of the entire /metadata/ tree >> without the entire /source/ tree > > This is something I agree with. It seems smart to be able to download > the metadata before downloading the source tree. This allows dependency > resolution, searches, etc. By the same token, it's smart to keep the metadata close to the thing it's describing, so if it's easy to extract up front reliably, that's probably sufficient. Larry
