Archive old uefi hint
[linux_from_scratch_hints.git] / fakeroot.txt
blob888ee83b4fa12814b05a4dcf4a3edac9c514ac82
1 AUTHOR: Tushar Teredesai <tushar AT linuxfromscratch DOT org>
3 DATE: 2006-01-17
5 LICENSE: BSD
7 SYNOPSIS: Fakeroot approach for package installation
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.
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.
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
26 PREREQUISITES:
27 None.
29 HINT:
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.
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.
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.
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>.
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.
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.
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.
168 CHANGELOG:
169 [2005-12-09]
170   * Initial Version of the hint.