If you look at the build directories for several packages that you have installed locally, you will find a large amount of redundancy. Every file that ends up in the perl/lib or perl/site/llin directories is replicated somewhere in the package build directories. And for every file that ends up there, there are two more in the build directories that only serve a purpose of containing meta information required by the build process. These are regenerated/replicated for every package.
If you look at the makefiles for a couple of Pure Perl packages, you'll find that they are hugely complex, when actually, simply putting the .pm file in the correct place suffices. The vast array of targets in generated makefiles are very rarely ever used by the average user. On those rare occasions where it is necessary to try and modify the generated makefiles for local reasons, it is a nightmare trying to work your way back through the generation process and work out what you need to change and where in order to affect the change that you know will fix the problem you are having building a given module.
An example. Every build I run generates gobs of warnings about the fact that the of the compiler I use does not allow optimisations. The change required is to omit the optimisation flag from the compiler command lines--but doing this for every package I download is a pain in the neck. Every compiler command line generated by EU::MM has the -On flag 2 and sometimes 3 times. Several other flags and defines are likewise added multiple times. All this contributes so much noise to the build process that it becomes literally impossible to decide from the build process if the compilation was good.
Attempting to first work out what needs to be changed and where and then add yet another build flag to enable that change so that the changes I would like to see for my combination of OS/compiler can be enabled for only that combination and not affect other environments is, for all intents and purposes, impossible. Trying to feed this information back to p5p and get them incorporated back into the distribution...
If a single module build process was used by each given installation, then tailoring that single build process to local requirements would a worthwhile exercise, but as is, it is pointless to expend the levels of energy required to do it for one package because you then have to repeat for every package that you install.
But the big problem is, we're trying to relate an idea that was aimed explicitly at P6, in terms of those things with which we are familiar ie. P5. The notion I had was that maybe, with the experience of the vast numbers of people here, we could collectively see a way to avoiding repeating the problems of P5 for P6.
P6 will use Parrot. Parrot has a platform independant intermediate bytcode form. In theory, there should be much less need for Perl6 modules too drop to C or XS because Parrot will be relatively efficient.
In theory, useing a module within your Perl6 program could load the precompiled bytecode directly from it's local DB. The local DB could (if authorised) have triggers set to go directly to CP6AN and fetch the bytecode, if it didn't already exist locally. It would even be possible to only fetch the bytecode for those methods of a class that get use. Though you would probably want to fetch the entire class from CP6AN to the local database and only defer loading the bytecode for individual methods until they are called (or seen to be called). That could allow lighter runtime memory consumption by only loading that code that is used.
Instead of distributing updated modules, or patches to modules, individual methods can be updated from CP6AN. Yes, there are trust issues here, though I wonder how many people actually read all the source files they download from CPAN now?
I'm not saying that any or all of these ideas are practical or desirable. Only that they are possible. And that if open discussion ensued about what is and is not possible, practical and desirable, now, before P6 becomes a reality and backwards compatibility becomes master, CP6AN could be a lighter, faster more flexible and more easily managed beast that generated statistics as it went along.
There are a zillion nice-to-haves that could fall out of having all the information within a database structure, that are simply impractical if P6 goes the P5 route.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco.
Rule 1 has a caveat! -- Who broke the cabal?