[gobolinux-devel] Installation of meta recipes

[Hisham Muhammad]

On 12/7/06, Laércio Benedito de Sousa Júnior <lbsousajr at gmail.com> wrote:
> 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.

You're right. Perhaps we used a bad name for our meta-recipes (but
then, we're not calling them "meta-packages" so strictly there's no
conflict). Distros often use different names for meta-packages ("task"
packages, virtual packages, etc) anyway.

> 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.

Oh, I understood your idea when I got to "the checksums of the stuff
don't need to be
verified" -- you're basically suggesting to use a "manifest" file (a
'checksums list without checksums'). It's an interesting idea.

> 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...

An interesting thought. Vim and Gvim comes to mind. We probably don't
need to use different names everytime we use different flags though.
But yes, this is the use-flags discussion all over again. I thought
long and hard about this, and I'm getting hopeless that a
nice-and-clean design for use-flags is possible (at least "nicer and
cleaner" than what Gentoo has). Maybe we just have to bite the bullet
and implement something very much like Portage's USE flags.

-- Hisham