OpenPKG CVS Repository
  http://www.openpkg.org/cvsweb/cvsweb.cgi
  ____________________________________________________________________________

  Server: cvs.openpkg.org                  Name:   Michael Schloh
  Root:   /e/openpkg/cvs                   Email:  [EMAIL PROTECTED]
  Module: openpkg-doc                      Date:   12-Jul-2002 12:41:39
  Branch: HEAD                             Handle: 2002071211413800

  Modified files:
    openpkg-doc/handbook    openpkg.xml

  Log:
    Added section on '--define' semi-customization of package building.

  Summary:
    Revision    Changes     Path
    1.48        +51 -1      openpkg-doc/handbook/openpkg.xml
  ____________________________________________________________________________

  Index: openpkg-doc/handbook/openpkg.xml
  ============================================================
  $ cvs diff -u -r1.47 -r1.48 openpkg.xml
  --- openpkg-doc/handbook/openpkg.xml  12 Jul 2002 09:40:40 -0000      1.47
  +++ openpkg-doc/handbook/openpkg.xml  12 Jul 2002 10:41:38 -0000      1.48
  @@ -999,6 +999,8 @@
           when installing OpenPKG. Later examine the captured text files for
           missing dependency failures.
         </para>
  +      <sect2>
  +      <title>Requirement Exceptions</title>
         <para>
           There exist some exceptions to these requirements. Installation of
           OpenPKG on Debian Linux will fail unless GNU gettext and libpam0g-dev
  @@ -1007,6 +1009,7 @@
           who may find a cc command on a freshly installed system to be nothing
           more than a useless wrapper script.
         </para>
  +      </sect2>
   <!--FIXME: Describe Solaris 9 and FreeBSD exact requirements-->
       </sect1>
   
  @@ -1407,7 +1410,54 @@
           <para>
             In any case, after building a source package via the rpm command,
             the resulting binary package will be written to the directory
  -          $opkg_root/RPM/PKG/.
  +          $opkg_root/RPM/PKG/. This binary package can be installed to any
  +          number of target systems as long as they all share the same hardware
  +          architecture and operating system. They should also all share the
  +          same relative path name to their respective OpenPKG instances. That
  +          means that if the source package was built for the OpenPKG instance
  +          at /mycw/, the resulting binary will always install to such a
  +          directory (creating it if necessary) on any system for which it is
  +          used. These constraints along with more general security concerns
  +          make it much more appealing to build source packages on each
  +          individual system, and install the resulting binary packages only on
  +          the system where they were made.
  +        </para>
  +      </sect2>
  +
  +      <sect2 id='install-custom'>
  +        <title>Semi-custom package building</title>
  +        <para>
  +          Most OpenPKG packages are made available after a close scrutiny from
  +          the OpenPKG developers leads to a level of consesus. This scrutiny
  +          involves analysis of what options the package in question offers,
  +          and which of them are most portable and most useful for typical
  +          server application. However, only one package will be available in
  +          the end.  This leads to the question, "What if several
  +          configurations of the same application should be packaged?" The
  +          OpenPKG way of dealing with this issue is offering a standard
  +          configuration as well as other configurations defined in the RPM
  +          .spec file. A package builder must choose from these configuration
  +          options by adding a '--define' option to the command line while
  +          building. The configuration argument follows the aforementioned
  +          option, and the whole build command may then look something like
  +          this:
  +        </para>
  +<screen>
  +<prompt>$</prompt> <userinput>rpm --rebuild package.src.rpm --define 
"with_option=yes"</userinput>
  +<prompt>$</prompt></screen>
  +        <para>
  +          This method of semi-customization works when building with
  +          '--rebuild' and '-bb' as well. Because the use of such custom
  +          definitions are not just limited to the build process, it is
  +          possible that the '--define' option will be used during installation
  +          as well. When in doubt, customize a package in this way by giving
  +          the same '--define' option at each step of the build and install
  +          process. For more information on how to use the custom configuration
  +          features of OpenPKG, a quick study of an RPM .spec file can yield
  +          much. Of course, choose a package which has such internal
  +          configuration variables. Search a .spec file for 'with_' to find out
  +          if the package offers such customization. This is also useful in
  +          learning which configuration options a package allows.
           </para>
         </sect2>
   
______________________________________________________________________
The OpenPKG Project                                    www.openpkg.org
CVS Repository Commit List                     [EMAIL PROTECTED]

Reply via email to