So, I'm a little bummed today, because I spent an hour of my time on the #toolchain IRC channel, trying to get some answers to my CPAN metadata questions. It was a nearly total waste of time, because I realized we're solving two entirely different, but cosmetically related problems.
For example, one of the senior guys (I say that 'cause he's written a lot of the CPAN-related tools) made the statement that "distribution versions are meaningless". In my opinion, that's nonsense, because the unit of update on CPAN is a numerically versionized tarball (or zip file, or whatever). The dissonance comes from the fact that in EFS, we're solving the GENERIC problem of how to deploy... versionized releases of software. The cpan2efs and minicpan code I've written solve that problem pretty well, with a few edge and corner cases I need to address. The #toolchain folks are focused almost entirely on MODULE dependencies. The other problem is that EFS turns the entire approach to software deployment upside down. Our hierarchy focuses on the product, then it's version, and THEN the various compilers and platforms it can be made available for. The rest of the world (and every single person on #toolchain) approaches this problem with the opposite hierarchy. You pick a platform, then you pick a compiler, and then you focus on installing (into ONE single integrated directory structure) all the products and versions you need. Because of this, tools like cpanp/cpanm/etc can simply start to install one CPAN distro, and DURING THAT INSTALLATION process, detect dependencies, and then recursively install them. When you have a SINGLE platform, and a SINGLE compiler, and a SINGLE directory structure, that's probably the right way to do it. For the overwhelming majority of perl users and developers, this is how they build and deploy software. It's not wrong; it's how you have to do things when you don't have a infrastructure like EFS. This approach can NOT be implemented in the current efsdeploy design, which is nothing more than the result of automating the workflow we've been using for over 15 years to build products into /efs (or /ms, it's predecessor). Still reading? Still wondering what "fakeefs" is? Keep reading :-) So, as I'm sure you know, I think there's a tremendous potential for EFS to be useful to the perl community in general, but sadly noone seems to be able to build decent NFS infrastructure anymore. (The EFS learning curve, and the paradigm shift is requires, are too alien to most people, and that's probably why it's doomed). Well, what if I came up with a way to get efsdeploy/cpan2efs to work for the single-platform, locally installed problem space? Well.... THAT is what fakeefs is. I looked closely at the nature of the efsdeploy/cpan2efs dependency on efs, and it's entirely via the CLI and the /efs directory structure. Like I've always said THAT is the only stable "API" to EFS. Anything that uses the EFS::* modules, or accesses the efs RDBMS is using interfaces that are subject to change. I'm going to create a very simple, fakeefs project that will include a VERY simple efs script, that does everything with mkdir. I think I can make it very easy to setup a fake /efs/dev and /efs/dist so that you can then setup and use efsdeploy/cpan2efs, although it will be limited to just 2 platforms: the 32 and 64 bit platforms associated with the local HW. Actually, I think "mockefs" is a better name, now that I think about it.
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
