I don't know if you agree, but the concept of meta-Recipes in GoboLinux is quite different of the concept of meta-packages in other installation systems. These ones (let me call them "virtual packages") do absolutely nothing but ask the management tool to install their "dependencies". GoboLinux meta-Recipes, instead, merge their "children" into a single package directory structure.
The correspondence between Recipes and Packages in GoboLinux is not bijective (Packages were made to be installed, while Recipes were made to build Packages, if I'm not wrong), and thus they don't need to be managed in the same way. Why not include, in each Recipe, a FileHash with the contents of the stuff generated when it is compiled (something like option 3 in the top message)? So, when recompiling a meta-Recipe, the FileHash'es of its "children" could be read and, if a "child's" stuff is already in place, the compilation of this one could be skipped (the checksums of the stuff don't need to be verified). This is some kind of Recipe management and won't break GoboLinux Package management. I wonder if GoboLinux could also support those "virtual Recipes" (or "virtual Packages"). Since there is no bijective correspondence between Recipes and Packages, and if several Recipes can be merged into a single Package (with meta-Recipes), I also wonder if a single Recipe could, conversely, provide several Packages (e.g.: the same Recipe for GCC could provide Packages for GCC-Fortran/GFortran and GCC-Java/GCJ; this feature would be an alternative to Portage-like USE flags). But this is another discussion...
_______________________________________________ gobolinux-devel mailing list [email protected] http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
