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 13:54:52
Branch: HEAD Handle: 2002071212545200
Modified files:
openpkg-doc/handbook openpkg.xml
Log:
Added section on multipackages.
Summary:
Revision Changes Path
1.49 +69 -3 openpkg-doc/handbook/openpkg.xml
____________________________________________________________________________
Index: openpkg-doc/handbook/openpkg.xml
============================================================
$ cvs diff -u -r1.48 -r1.49 openpkg.xml
--- openpkg-doc/handbook/openpkg.xml 12 Jul 2002 10:41:38 -0000 1.48
+++ openpkg-doc/handbook/openpkg.xml 12 Jul 2002 11:54:52 -0000 1.49
@@ -443,7 +443,9 @@
Namely, the package is configured for a particular platform and
subsequently built. The vendor sources are typically compiled
according a <filename>Makefile</filename> of some sort, and the
- resulting file structure is ready for installation.
+ resulting file structure is ready for installation. Command line
+ options can be used to manipulate the options a package offers, as
+ explained in <xref linkend='install-custom'/>.
</para>
<screen>
<prompt>$</prompt> <userinput>rpm -bc --short-circuit foo.spec</userinput></screen>
@@ -458,7 +460,9 @@
the distributed package, this stage of installation must use its own
directory and not $opkg_root as is usually the case. The developer
therefore redirects the package to a fake installation hierarchy,
- and installs the vendor objects.
+ and installs the vendor objects. Command line options can be used to
+ manipulate the options a package offers, as explained in <xref
+ linkend='install-custom'/>.
</para>
<screen>
<prompt>$</prompt> <userinput>rpm -bi --short-circuit foo.spec</userinput></screen>
@@ -471,7 +475,9 @@
package, the contents of the vendor object installation are rolled
(bundled) into a single binary file. A wise developer will first
inspect the installation hierarchy to ensure that no temporary or
- residual files are included in the package.
+ residual files are included in the package. Command line options can
+ be used to manipulate the options a package offers, as explained in
+ <xref linkend='install-custom'/>.
</para>
<screen>
<prompt>$</prompt> <userinput>rpm -bs foo.spec</userinput>
@@ -1458,6 +1464,66 @@
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>
+
+ <sect2 id='install-multipak'>
+ <title>Multipackages</title>
+ <para>
+ Even with the flexibility offered by semi-custom package building,
+ there are cases of additional functionality that can't be collected
+ in a single package. The most typical example of this is if two
+ different versions of an application must be packaged. Needless to
+ say, the strategy of building multipackages to satisfy diverse needs
+ is a rather complicated and somewhat dangerous one. Problems such as
+ redundancy in package specifications, visual inconsistencies of
+ comparable normal packages, and conflicting installation files can
+ arise to the detriment of both the packaging and installing
+ engineer. Because of these drawbacks, multipackages were long
+ discouraged and didn't even exist in the package repository.
+ Starting with OpenPKG release 1.1 they do exist, and the installing
+ engineer can remain calm due to the following considerations made by
+ each packager when dealing with multipackages.
+ <orderedlist>
+ <listitem>
+ <simpara>
+ Multipackages are made only when absolutely necessary, and when
+ so, a minimum number of versions will be used! This should keep
+ down the number of multipackages in the OpenPKG package
+ repository to just a few, or at least less than ten.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Multipackages are considered only for software with major
+ differences in vendor versions. Issues regarding minor
+ differences or dificult upgrade paths are to be resolved without
+ multipackaging the software.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ If possible, multipackages should be installable in parallel
+ within the same OpenPKG instance. No files or paths should
+ conflict. However, if they must conflict, the packager must
+ provide a reasonable Conflicts: header in the RPM .spec file.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ If multiple versions of package 'foo' exist as multipackages,
+ they are named 'foo' and 'fooX' where 'foo' must be the latest
+ stable vendor version (both conditions!) Package 'fooX' can be
+ either an older version or a newer one that is known to be
+ unstable. The 'X' in 'fooX' is taken from the first one or two
+ numbers of the vendor version with all punctuation stripped off.
+ For example, some multipackages residing in the OpenPKG package
+ repository to date are gcc2-2.95.4 and gcc-3.1, db3-3.3.11 and
+ db-4.0.x, apache-1.3.32 and apache2-2.0.32, mysql-3.x.x and
+ mysql4-4.0.x, and freetype1-1.3.1 and freetype-2.0.x.
+ </simpara>
+ </listitem>
+ </orderedlist>
</para>
</sect2>
______________________________________________________________________
The OpenPKG Project www.openpkg.org
CVS Repository Commit List [EMAIL PROTECTED]
