[Bug-gnulib] Re: relocatable packages

[Alexandre Duret-Lutz]

Hi Bluno!

>>> "Bruno" == Bruno Haible <address@hidden> writes:

 Bruno> Hi all,
 Bruno> It has been a pain for many users of GNU packages for a long time that
 Bruno> packages are not relocatable. It means a user cannot copy a program,
 Bruno> installed by another user on the same machine, to his home directory,
 Bruno> and have it work correctly (including i18n). So many users need to go
 Bruno> through "configure; make; make install" with all its dependencies,
 Bruno> options and hurdles.

 Bruno> rpms and similar package systems solve the "ease of installation"
 Bruno> problem but have a drawback: they hardwire path names, usually to /usr
 Bruno> or /usr/local, with the consequences that
 Bruno> - Users need root privileges to install a binary package,
 Bruno> - It is impossible to have two different versions of the same
 Bruno> package installed (which makes Unix not better than Woe32 in this
 Bruno> aspect).

If memory serves me right, RPM has an option to relocate
packages (i.e., install them in a different root).  Of course
this assumes the package is relocatable, which is the point of
your mail.

[...]

 Bruno> The runtime penalty and size penalty are nearly zero on
 Bruno> Linux (just one system call more when an executable is
 Bruno> launched), and small on other systems (the wrapper
 Bruno> program just sets an environment variable and execs the
 Bruno> real program).

Is there any other justification to the --enable-relocatable
option, other than avoiding this small penalty?  I'd find
preferable that relocation be mandatory.  If you leave this as
an options, packagers (e.g. people who build RPM package) will
not use it, and people will have to make their own
./configure&&make&&make install anyway.

If packages are always built relocatable, then in many years we
might reach the point where you can download a random RPM and
install it in your account.

Plus it's one less option for the installer to deal with, and
one less configuration for the maintainer to debug.

[...]

 Bruno> * lib/Makefile.am

 Bruno> Assuming that your Makefile gathers all modules in a libfoo.a, you'll
 Bruno> have to add:
 Bruno> - to libfoo_a_SOURCES
 Bruno> error.h error.c
 Bruno> pathmax.h
 Bruno> progname.h progname.c
 Bruno> xmalloc.h xmalloc.c xstrdup.c
 Bruno> xreadlink.h xreadlink.c
 Bruno> - to libfoo_a_LIBADD
 Bruno> @ALLOCA@ @LIBOBJS@
 Bruno> (or @LTALLOCA@ @LTLIBOBJS@ if you link libfoo with libtool)

Now that Automake (>=1.7) no longer misses any AC_SUBST, we
recommend writing $(FOOBAR) over @address@hidden  @-substitutions
are internal details users should not have to worry about
in Makefile.am.

 Bruno> - to EXTRA_DIST
 Bruno> alloca_.h alloca.c
 Bruno> canonicalize.h canonicalize.c
 Bruno> memmove.c
 Bruno> relocatable.h relocatable.c
 Bruno> relocwrapper.c
 Bruno> setenv.h setenv.c unsetenv.c
 Bruno> strerror.c

If these are the files which will be AC_LIBOBJed, then you might
as well list the .h files in libfoo_a_SOURCES, and suppress the
EXTRA_DIST.  .c files should be distributed automatically, just
because they appear in a AC_LIBOBJ call.

[...]

 Bruno> And the following also also necessary, once per
 Bruno> Makefile.am that installs a program:

 Bruno> # Support for relocatability.
 Bruno> RELOCATABLE_LIBRARY_PATH = $(libdir)
 Bruno> RELOCATABLE_SRC_DIR = $(top_srcdir)/lib
 Bruno> RELOCATABLE_BUILD_DIR = ../lib
 Bruno> RELOCATABLE_CONFIG_H_DIR = ..
 Bruno> @SET_RELOCATABLE@

This looks like the kind of things Automake would be able to
output automatically with a bit of help from AC_RELOCATABLE.  Is
there any other place where Automake support would be needed?

[...]

An old project of mine that I haven't touched for months
(http://heroes.sourceforge.net/), is relocatable too.  I'll
summarize this here just to give a different view on relocation,
but actually I don't think you'll find anything interesting to
reuse.  

I had different needs, so relocation is done a bit differently.
First of all, I don't have shared libraries, so things are a lot
easer.

In Heroes, the impetus for relocation comes from the need to
support platforms like Windows or BeOS where people are
accustomed to unpack programs in random directories and run them
from there.  (Heroes is a game, and Windows gamers are often
clueless.)

Another thing I wanted was the possibility to run the binary
installed in the system, but change one of the files it uses
using some user configuration.  I've found this very conveniant
during development.

So what I have is a gperf-keyed database of filenames.  It looks
as follows.

arrow-img,              "$(data-dir)/pics/arrow.pcx",           0,0,true
data-dir,               "$(prefix)/"FORWARD_RELATIVE_PKGDATADIR,0,0,true
editor-img,             "$(data-dir)/pics/edit.pcx",            0,0,true
saved-games-file,       "$(user-dir)/savedgames",               0,0,true
home-dir,               "is initialized from $HOME",            0,0,true
locale-dir,             "$(prefix)/"FORWARD_RELATIVE_LOCALEDIR, 0,0,true
prefix,                 PREFIX,                                 0,0,true
user-dir,               "$(home-dir)/.heroes",                  0,0,true

(The full file is here
http://savannah.nongnu.org/cgi-bin/viewcvs/heroes/heroes/src/rsc_files.gperf?rev=1.26&content-type=text/plain
)

The code always make references to files through their keys
(like "arrow-img"), and the keys are also used in run-time
configurations files to override filenames or paths when needed.

PREFIX, FORWARD_RELATIVE_LOCALEDIR, and FORWARD_RELATIVE_PKGDATADIR
are static config.h definitions.  PREFIX is a straight copy of configure's
$prefix.  FORWARD_RELATIVE_LOCALEDIR and FORWARD_RELATIVE_PKGDATADIR
are paths equivalent of $localedir and $pkgdatadir, but *relative*
to $prefix.  I compute these relative paths at configure time
using the following macros 
  http://www.gnu.org/software/ac-archive/htmldoc/relpaths.html
  http://www.gnu.org/software/ac-archive/htmldoc/normpath.html

(http://www.gnu.org/software/ac-archive/htmldoc/stdrelpaths.html
can be used to define relative path for all the GNU Standards
directories, this is quite overkill.)

Relocation is done by probing for a data file and overriding the
value of `prefix'.  If the file exists in the default state
there is nothing to do.  (That means it's ok to copy or hard link
the executable anywhere, as long as the data files are still in
there default location.)  Otherwise if it can't find the file
and the user didn't help by setting a HEROES_PREFIX envvar, it
tries to derive the right prefix from argv[0], or by browsing
$PATH.

That procedure is readable here:
http://savannah.nongnu.org/cgi-bin/viewcvs/heroes/heroes/src/relocate.c?rev=1.11&content-type=text/vnd.viewcvs-markup

I didn't know about readlink(/proc/self/exe) or
GetModuleFileName(NULL,...)  until I read your mail.  Probably I
should do that too, if I ever work back on this game.
-- 
Alexandre Duret-Lutz