guild hall expectations

guild hall expectations

[Andy Wingo]

Hi,

Let's imagine there is a foo package, containing foo.scm.  Its current
version is 1, and we don't have it installed.  What happens when we
`guild install foo'?

Obviously the bundle is downloaded and unpacked.  But where to put the
files?  We could put them in the user's .local tree; we could put them
in Guile's directory; or somewhere else even.  If we put them in the
system directory there is the danger of interfering with the package
manager.  OTOH it could be convenient, sometimes.  If by default we put
them outside the GUILE_LOAD_PATH it would be inconvenient.

What I propose is that we do something like GNU stowfs does: install the
files to a $DESTDIR, and then link them into place.  The $DESTDIR would
be configurable, via dorodango's destination facility.  The linked-dir
could be be the system, the user's ~/.local, or even into a specific
project.  We would keep track of link mutations so that we could roll
back, possibly to a version of a file controlled by the distro's package
manager, though I don't think we'd implement that in the beginning.  It
does at least allow us to detect conflicts with packages installed via
other means.

This strategy also allows us to separate the phases a bit more
(download, install to stowfs, compile, link).  By default we always
store to ~/.local, so the the first three operations run unprivileged.
If we want to install to a system dir, the `link' phase could be run
under sudo (or fakeroot, even).

I'll see about hacking this up.  It's probably the last major hack that
our dorodango branch needs.  Hopefully it can be made in some
upstream-friendly way.

Regards,

Andy
-- 
http://wingolog.org/

Re: guild hall expectations

[Ludovic Courtès]

Hi Andy!

And sorry for the late reply.

Andy Wingo <wingo@pobox.com> skribis:

> What I propose is that we do something like GNU stowfs does: install the
> files to a $DESTDIR, and then link them into place.  The $DESTDIR would
> be configurable, via dorodango's destination facility.  The linked-dir
> could be be the system, the user's ~/.local, or even into a specific
> project.  We would keep track of link mutations so that we could roll
> back, possibly to a version of a file controlled by the distro's package
> manager, though I don't think we'd implement that in the beginning.  It
> does at least allow us to detect conflicts with packages installed via
> other means.

Sounds like a good idea!

This is roughly what Nix does: there’s the “Nix store”, which contains
installed packages, and there’s the “profile”, which is a symlink forest
to what’s currently installed in the user’s environment.

The nice thing is that updating the symlink forest can be transactional:
prepare the new symlink forest somewhere and, when you’re done,
rename(2) the “current environment” symlink.  And, as you say, you could
keep links to previous environments, thus allowing for rollback.

However, if you take that route, you’ll also need a garbage collector to
reclaim installed packages not referred to by any of the environments
kept around.

Thanks,
Ludo’.

PS: FTR stowfs in practice is actually a unionfs,
    <https://www.gnu.org/s/hurd/hurd/translator/unionfs.html>.  The rest
    is abstract plans.  ;-)