fakeroot.txt

   1 AUTHOR: Tushar Teredesai <tushar AT linuxfromscratch DOT org>
   2
   3 DATE: 2006-01-17
   4
   5 LICENSE: BSD
   6
   7 SYNOPSIS: Fakeroot approach for package installation
   8
   9 DESCRIPTION:
  10 LFS and BLFS instructions install files directly into the root directory
  11 without any kind of package management. Except for some simplistic cases, not
  12 having some sort of package management on the system will lead to problems.
  13
  14 In this hint, I discuss a style of package management that is most commonly used
  15 by distros - the fakeroot approach. And looking at the advantages, it is no
  16 wonder why it is the most popular method.
  17
  18 ATTACHMENTS:
  19 * http://www.linuxfromscratch.org/hints/downloads/attachments/autotools-multiversion/autoconf-wrapper
  20 * http://www.linuxfromscratch.org/hints/downloads/attachments/autotools-multiversion/automake-wrapper
  21 * http://www.linuxfromscratch.org/patches/download/autoconf/autoconf-2.13-race.patch
  22 * http://www.linuxfromscratch.org/patches/download/autoconf/autoconf-2.13-fedora_macro_fixes-1.patch
  23 * http://www.linuxfromscratch.org/patches/download/automake/automake-1.4-p6-fedora_fixes.patch
  24 * http://www.linuxfromscratch.org/patches/download/automake/automake-1.5-fedora_fixes.patch
  25
  26 PREREQUISITES:
  27 None.
  28
  29 HINT:
  30
  31 In the fakeroot approach, instead of installing the files into the final
  32 location (i.e. /), the files are installed into a temporary location and then
  33 moved to a different location. The way to achieve this is package dependent.
  34 Generally, the compilation instructions are identical to what you will find in
  35 the LFS or BLFS book. It is only during the installation that you need to modify
  36 the instructions.
  37
  38 Before going into the details of the approach, let us check out the advantages
  39 of the fakeroot approach so that you can decide whether it is the right
  40 technique for your system.
  41   * Does not require any additional packages to be installed on the system.
  42   * Allows manipulating the installed files before then end up in their final
  43     location. This removes patches in LFS such as coreutils-remove-XXX.patch
  44     that will never be accepted upstream. It also allows performing various
  45     maintainence operations such as compressing man and info pages. It also
  46     allows you to not allow the package to replace certain files (such as
  47     configuration files).
  48   * Allows upgrading packages on a live system (including packages such as
  49     glibc). Anyone who has tried to upgrade qt while logged into kde knows
  50     what I am talking about:) Bumping off users for the duration of package
  51     upgrades reflects poorly on the system administrator IMO.
  52   * If the package installation fails for some reason, there won't be a
  53     "half-baked" pacakge in /. Though a bit extreme, consider the following
  54     example. You are building gcc in BLFS and run into a problem during make
  55     install. You may be fscked since a partial gcc is installed in / which may
  56     or may not run. You have also destroyed the previously installed gcc. If
  57     you had installed it in fakeroot, you could have investigated the cause,
  58     corrected the problem, removed the fakeroot directory and installed the
  59     files again.
  60   * Allows checking of conflicts before the package is installed. For example,
  61     heimdal installs executables that overwrite executables from other
  62     packages. If you blindly install heimdal into / you may not notice it
  63     until its too late.
  64   * Provides a clear distinction between post installation configuration. LFS
  65     and BLFS only talk about installing packages (and sometimes about
  66     upgrading packages) but never about removing packages. Some packages are
  67     particularly hard to remove. Just removing the files that were installed
  68     by the package is not enough, you also need to run additional commands.
  69     For example, for the GNOME packages you may need to uninstall schemas and
  70     regenerate scrollkeeper files. With the fakeroot approach, you will soon
  71     get into the habit of performing two additional steps:
  72     - post install config: Steps to be performed after the package is
  73       relocated to /.
  74     - post removal config: Steps to be performed after the package is removed.
  75       Generally, this reverses whatever was done by the post install config.
  76
  77 The steps to installing a package with this approach are as follows. If you
  78 are creating scripts for package installation, each of the following can be a
  79 function of its own.
  80   *) Unpack the source and apply patches if required.
  81        tar -xvf $pkg-$ver.tar.bz2
  82   *) Compile.
  83        cd $pkg-$ver
  84        ./configure --prefix=/usr
  85        make
  86   *) Optionally test the package.
  87        make -k check
  88   *) Install into fakeroot. Adjust the FAKEROOT envar to suit your system.
  89        FAKEROOT=/usr/fakeroot/$pkg-$ver
  90        make DESTDIR=$FAKEROOT install
  91   *) Perform whatever maintainence you need on the installed files.
  92   *) If upgrading the packaqge, perform post removal config steps for the
  93      previously installed version.
  94   *) Relocate the package to the final destination.
  95        cd $FAKEROOT
  96        tar cf - . | (cd / ; tar xf - )
  97   *) Perform post install configuration.
  98   *) If upgrading a package, remove files left over by the previous version.
  99
 100 Hopefully, now you are convinced that the fakeroot approach is the right
 101 approach for you. So lets get down to the details on how to achieve this.
 102 Since it is impossible to include instructions for all the packages in LFS and
 103 BLFS, I will go through some common ways to install packages into fakeroot. If
 104 you get stuck in a particular package:
 105 * Check out my build scripts at
 106   <http://linuxfromscratch.org/~tushar/build-scripts/>.
 107 * Check out Gentoo Ebuilds at <http://www.gentoo.org/cgi-bin/viewcvs.cgi/>.
 108 * Check out Fedora spec files at
 109   <http://cvs.fedora.redhat.com/viewcvs/?root=core>.
 110
 111 Ways to install into fakeroot:
 112 * Installation controlled using an envar.
 113   Since the fakeroot approach is the most commonly used approach for package
 114   management, lot of package maintainers use an easy way to control the
 115   installation. Also, since most packages use autotools, the envar for
 116   fakeroot is DESTDIR. Hence the installation for this kind of packages would
 117   be
 118     make DESTDIR=$FAKEROOT install
 119   Some packages may use a different envar for fakeroot. For example, glibc
 120   uses install_root. Check the INSTALL file in the package to find the envar.
 121 * Installation by modifying prefix during installation.
 122   For some older packages, a simple way to make the packages install into
 123   fakeroot is to change the prefix variable during installation.
 124     make prefix=$FAKEROOT/usr install
 125 * Manual installation.
 126   Some packages are stubborn. Sometimes it is easier to install all files
 127   manually. This is convinient for packages that do not install few files.
 128
 129 Things to look out for:
 130 * Sometimes packages do not create the destination file before installing
 131   files into a dir. Normally when installing into / this is not a problem
 132   since the destination dir such as /usr/bin would already have been created.
 133   But when installing into a fakeroot, you may need to create these dirs
 134   manually using install -d.
 135 * A small minority of packages hardcode the fakeroot directory into the files.
 136   It is generally a good idea to peruse the logs.
 137 * Packages that install info pages create a file /usr/share/info/dir. This
 138   file should be recreated after the package is install. Refer to the LFS
 139   book's section on texinfo on how to regenrate this file.
 140 * Perl modules have two problems. One is that the file .packlist hardcodes the
 141   FAKEROOT dir in it. This needs to be removed using sed. Additionally, each
 142   module installs a shared file perllocal.pod. If the module is installed
 143   directly into /, the installation would have appended the new contents to
 144   the file. Since we install into a fakeroot, we need to manually append
 145   this file to the system installed perllocal.pod and prevent installation of
 146   the perllocal.pod installed by the module.
 147 * Packages that install GConf schemas install the schemas automatically during
 148   make install. Since we are installing into a fakeroot, this step needs to be
 149   performed in the post installation config step. To disable installation of
 150   the schmeas, either set the GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL var to
 151   true during make install or pass the --disable-schema-install switch to
 152   configure.
 153 * For packages that install scrollkeeper catalogs, the scrollkeeper-update
 154   process needs to be disabled during installation and the scrollkeeper
 155   database needs to be updated in the post installation config.
 156 * For packages that install fonts, fc-cache and gtk-updated-icon-cache needs to
 157   be called during post installation config phase.
 158 * For packages that install gtk immodules and loaders, the configuration needs
 159   to be recreated manually by calling gtk-query-immodules and
 160   gdk-pixbuf-query-loaders.
 161 * For packages that install mime db files, the mime database needs to be
 162   updated manually by calling update-mime-database.
 163
 164 If you feel adventorous, you can combine this hint with the pkg-user hint for
 165 the unlimate package manager scheme:-) I have been using that for quite some
 166 time and even though it is a little bit complex, it has served me well.
 167
 168 CHANGELOG:
 169 [2005-12-09]
 170   * Initial Version of the hint.