Overlays

[ludo@gnu.org (Ludovic Courtès)]

Cyprien Nicolas <cyprien@nicolas.tf> skribis:

> "Portage" (the tool used to install packages from source, through the
> "emerge" command) looks for ebuild in that directory, but it can also
> looks from other directories which follow the same structure, those
> directories are called "overlays", as they can mask packages from the
> official tree, but also extend it.

OK, I see.

In Guix, packages (equivalent to “ebuilds”, AIUI) are just Scheme
objects.  Normally, they are exported by Guile modules; the GNU system
exports packages from the (gnu packages ...) name space, but users are
free to create other modules that define and export packages.

The ‘guix build’ and ‘guix package’ commands traverse the list of
modules in the (gnu packages ...) name space.  Thus, if you type:

  guix build hop

the whole list packages exported by (gnu packages ...) modules is
traversed in search of one whose name is “hop”.

But you can also run:

  guix build -e '(@ (my own packages) hop)'

to refer to a specific package definition in your own module.


Now, there is currently no way to instruct the command-line tools to
also look under (my own packages), for instance.  That may be a useful
thing to add.

> However, overlay create new concerns.  First, priority of overlays, if
> two provide the same package-version combination, which one to choose?
> If Overlay A provide Package P, which depends on Library L, not in
> Overlay A but in the "base" repository, and that Overlay B provide
> a newer version of Library L, which L to choose?

In Guix the dependency graph is really a graph of Scheme objects, so
there’s no ambiguity as to what they refer to.

So I think Guix nearly supports overlays, no?  :-)

The way forward is to identify precise mechanisms needed to better
support overlay-style uses, and then to come up with patches (patches
that are simple enough could go in for 0.4.)

A good starting point is the ‘fold-packages’ procedure in (gnu packages).

WDYT?

Thanks,
Ludo’.