pkgmgt.html

CLFS(Cross-Compiled Linux From Scratch)的文档 Version CLFS-SVN-20060417

            Environment variables such as <tt class="envar">PATH</tt>,
            <tt class="envar">LD_LIBRARY_PATH</tt>, <tt class=
            "envar">MANPATH</tt>, <tt class="envar">INFOPATH</tt> and
            <tt class="envar">CPPFLAGS</tt> need to be expanded to include
            <tt class="filename">/usr/pkg/foo</tt>. For more than a few
            packages, this scheme becomes unmanageable.
          </p>
        </div>
        <div class="sect3" lang="en" xml:lang="en">
          <div class="titlepage">
            <div>
              <div>
                <h4 class="title">
                  <a id="id3660710" name=
                  "id3660710"></a>10.2.2.3.&nbsp;Symlink Style Package
                  Management
                </h4>
              </div>
            </div>
          </div>
          <p>
            This is a variation of the previous package management technique.
            Each package is installed similar to the previous scheme. But
            instead of making the symlink, each file is symlinked into the
            <tt class="filename">/usr</tt> hierarchy. This removes the need
            to expand the environment variables. Though the symlinks can be
            created by the user to automate the creation, many package
            managers have been written using this approach. A few of the
            popular ones include Stow, Epkg, Graft, and Depot.
          </p>
          <p>
            The installation needs to be faked, so that the package thinks
            that it is installed in <tt class="filename">/usr</tt> though in
            reality it is installed in the <tt class="filename">/usr/pkg</tt>
            hierarchy. Installing in this manner is not usually a trivial
            task. For example, consider that you are installing a package
            libfoo-1.1. The following instructions may not install the
            package properly:
          </p>
          <pre class="userinput">
<kbd class="command">./configure --prefix=/usr/pkg/libfoo/1.1
make
make install</kbd>
</pre>
          <p>
            The installation will work, but the dependent packages may not
            link to libfoo as you would expect. If you compile a package that
            links against libfoo, you may notice that it is linked to
            <tt class="filename">/usr/pkg/libfoo/1.1/lib/libfoo.so.1</tt>
            instead of <tt class="filename">/usr/lib/libfoo.so.1</tt> as you
            would expect. The correct approach is to use the <tt class=
            "envar">DESTDIR</tt> strategy to fake installation of the
            package. This approach works as follows:
          </p>
          <pre class="userinput">
<kbd class="command">./configure --prefix=/usr
make
make DESTDIR=/usr/pkg/libfoo/1.1 install</kbd>
</pre>
          <p>
            Most packages support this approach, but there are some which do
            not. For the non-compliant packages, you may either need to
            manually install the package, or you may find that it is easier
            to install some problematic packages into <tt class=
            "filename">/opt</tt>.
          </p>
        </div>
        <div class="sect3" lang="en" xml:lang="en">
          <div class="titlepage">
            <div>
              <div>
                <h4 class="title">
                  <a id="id3660821" name=
                  "id3660821"></a>10.2.2.4.&nbsp;Timestamp Based
                </h4>
              </div>
            </div>
          </div>
          <p>
            In this technique, a file is timestamped before the installation
            of the package. After the installation, a simple use of the
            <span><strong class="command">find</strong></span> command with
            the appropriate options can generate a log of all the files
            installed after the timestamp file was created. A package manager
            written with this approach is install-log.
          </p>
          <p>
            Though this scheme has the advantage of being simple, it has two
            drawbacks. If, during installation, the files are installed with
            any timestamp other than the current time, those files will not
            be tracked by the package manager. Also, this scheme can only be
            used when one package is installed at a time. The logs are not
            reliable if two packages are being installed on two different
            consoles.
          </p>
        </div>
        <div class="sect3" lang="en" xml:lang="en">
          <div class="titlepage">
            <div>
              <div>
                <h4 class="title">
                  <a id="id3661057" name=
                  "id3661057"></a>10.2.2.5.&nbsp;LD_PRELOAD Based
                </h4>
              </div>
            </div>
          </div>
          <p>
            In this approach, a library is preloaded before installation.
            During installation, this library tracks the packages that are
            being installed by attaching itself to various executables such
            as <span><strong class="command">cp</strong></span>,
            <span><strong class="command">install</strong></span>,
            <span><strong class="command">mv</strong></span> and tracking the
            system calls that modify the filesystem. For this approach to
            work, all the executables need to be dynamically linked without
            the suid or sgid bit. Preloading the library may cause some
            unwanted side-effects during installation. Therefore, it is
            advised that one performs some tests to ensure that the package
            manager does not break anything and logs all the appropriate
            files.
          </p>
        </div>
        <div class="sect3" lang="en" xml:lang="en">
          <div class="titlepage">
            <div>
              <div>
                <h4 class="title">
                  <a id="id3660834" name=
                  "id3660834"></a>10.2.2.6.&nbsp;Creating Package Archives
                </h4>
              </div>
            </div>
          </div>
          <p>
            In this scheme, the package installation is faked into a separate
            tree as described in the Symlink style package management. After
            the installation, a package archive is created using the
            installed files. This archive is then used to install the package
            either on the local machine or can even be used to install the
            package on other machines.
          </p>
          <p>
            This approach is used by most of the package managers found in
            the commercial distributions. Examples of package managers that
            follow this approach are RPM (which, incidentally, is required by
            the <a href=
            "http://lsbbook.gforge.freestandards.org/package.html#RPM"><i>Linux
            Standard Base Specification</i></a>), pkg-utils, Debian's apt,
            and Gentoo's Portage system. A hint describing how to adopt this
            style of package management for LFS systems is located at
            <a href="http://www.linuxfromscratch.org/hints/downloads/files//fakeroot.txt">
            <i>http://www.linuxfromscratch.org/hints/downloads/files//fakeroot.txt</i></a>.
          </p>
        </div>
        <div class="sect3" lang="en" xml:lang="en">
          <div class="titlepage">
            <div>
              <div>
                <h4 class="title">
                  <a id="id3660703" name="id3660703"></a>10.2.2.7.&nbsp;User
                  Based Management
                </h4>
              </div>
            </div>
          </div>
          <p>
            This scheme, unique to LFS, was devised by Matthias Benkmann, and
            is available from the <a href=
            "http://www.linuxfromscratch.org/hints/downloads/files/"><i>Hints
            Project</i></a>. In this scheme, each package is installed as a
            separate user into the standard locations. Files belonging to a
            package are easily identified by checking the user ID. The
            features and shortcomings of this approach are too complex to
            describe in this section. For the details please see the hint at
            <a href=
            "http://www.linuxfromscratch.org/hints/downloads/files//more_control_and_pkg_man.txt">
            <i>http://www.linuxfromscratch.org/hints/downloads/files//more_control_and_pkg_man.txt</i></a>.
          </p>
        </div>
      </div>
    </div>
    <div class="navfooter">
      <ul>
        <li class="prev">
          <a accesskey="p" href="chapter.html" title=
          "Installing Basic System Software">Prev</a>
          <p>
            Installing Basic System Software
          </p>
        </li>
        <li class="next">
          <a accesskey="n" href="testsuitesagain.html" title=
          "About Test Suites, Again">Next</a>
          <p>
            About Test Suites, Again
          </p>
        </li>
        <li class="up">
          <a accesskey="u" href="chapter.html" title=
          "Chapter&nbsp;10.&nbsp;Installing Basic System Software">Up</a>.
        </li>
        <li class="home">
          <a accesskey="h" href="../index.html" title=
          "Cross-Compiled Linux From Scratch - Version CLFS-SVN-20060417-MIPS">
          Home</a>.
        </li>
      </ul>
    </div>
  </body>
</html>