[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

guild hall expectations

From: Andy Wingo
Subject: guild hall expectations
Date: Sat, 03 Sep 2011 14:54:00 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)


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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]