OpenPKG CVS Repository
http://cvs.openpkg.org/
____________________________________________________________________________
Server: cvs.openpkg.org Name: Ralf S. Engelschall
Root: /e/openpkg/cvs Email: [EMAIL PROTECTED]
Module: openpkg-web Date: 29-Jul-2003 20:52:12
Branch: HEAD Handle: 2003072919521200
Modified files:
openpkg-web faq.wml
Log:
one entry obsoleted by OpenPKG 1.3, two new added for answering new
things
Summary:
Revision Changes Path
1.39 +63 -32 openpkg-web/faq.wml
____________________________________________________________________________
patch -p0 <<'@@ .'
Index: openpkg-web/faq.wml
============================================================================
$ cvs diff -u -r1.38 -r1.39 faq.wml
--- openpkg-web/faq.wml 12 Jul 2003 19:38:24 -0000 1.38
+++ openpkg-web/faq.wml 29 Jul 2003 18:52:12 -0000 1.39
@@ -430,38 +430,6 @@
</ol>
</faq>
-<faq id="why-compress"
- title="Why does/did the OpenPKG bootstrap use \"compress\" data format?">
- The "<tt>openpkg*.src.sh</tt>" source bootstrap should run on as
- many platforms as possible. All platforms within the scope of
- OpenPKG support unpacking of data that comes in "compress" format.
- This is true for very old but still in production UNIX systems. It
- is also true for very new LINUX systems which do not have an
- uncompress(1) tool installed by default but come with a gunzip(1)
- which can unpack "compress" format and is detected and used by the
- bootstrap. There is no other packed data format with equal
- availability.
- <p>
- When a user creates a
- "<tt>openpkg-*.<i>arch</i>-<i>os</i>-<i>hierarchy</i>.sh</tt>"
- binary bootstrap the resulting script was in "compress" format in
- OpenPKG v1.0, v1.1 and CURRENT until 20030110. This required the
- availability of compress(1) to the user. As described above, the
- latest incarnations of LINUX omit that crucial tool and gzip(1) is
- not a full featured replacement as it cannot create "compress"
- format. For this reason we dropped compression for binary bootstrap
- entirely beginning with CURRENT 20030113 and OpenPKG v1.2 and now
- keep the data verbatim.
- <p>
- Further research proved that due to fact that only half a megabyte
- of sources are unpacked and the remaining sources already come in
- "gzip" format the use of "compress" format for the whole thing
- actually enlarged the "<tt>openpkg-*.src.sh</tt>" file. For this
- reason we dropped compression for source bootstrap entirely
- beginning with CURRENT 20030114 and OpenPKG v1.2 and now keep the
- data verbatim.
-</faq>
-
<faq id="uid-security"
title="What is the fuzz about those multiple user/group ids in OpenPKG?">
Starting with OpenPKG 1.1 the bootstrapping package ("openpkg") uses
@@ -630,6 +598,69 @@
VER-REL</tt>", provided by the packages "<tt>gcc</tt>",
"<tt>gcc32</tt>", "<tt>gcc34</tt>", etc.
</ul>
+</faq>
+
+<faq id="source-focus"
+ title="Why does OpenPKG focus on source RPMs only?">
+ OpenPKG by design focuses on source RPMs and the building and installing
+ directly from them. Binary RPMs are just an intermediate and temporary
+ result in this approach. From our perspective, they exist just temporarily
+ on the target machine or on our FTP server because of bootstrapping and for
+ emergency situations only. There are multiple reasons for this. The most
+ important are:
+ <p>
+ <ul>
+ <li>Stability: binary RPMs are inherently weak when it comes to run-time
+ stability. The reason is that there are <i>always</i> differences
+ between the build and install host -- sometimes more, sometimes less.
+ But just the smallest difference (versions of vendor shared
+ libraries, different kernel patch-levels, system configuration
+ differences, etc) can lead to a broken application on the install
+ host due to inherited assumptions from the build host.
+ <p>
+ Example: build host has higher configured maximum allowed
+ size for shared memory segments (usually because runs also a
+ RDBMS), building OSSP mm on it determines this high limit and
+ has to hard-code this into the package, package is deployed
+ to install host and breaks horrible because install host has
+ default maximum allowed size for shared memory. Bang! And OSSP
+ mm has no chance, some parameters of a system cannot be easily
+ determined under run-time. Instead they have to be determined
+ in a complex way under configuration/build-time.
+ <p>
+ <li>Flexibility: OpenPKG source RPMs often have a bunch of build
+ "options" (can be queried with <tt>rpm -qpi</tt>) for allowing one to
+ build a package in multiple different <i>variants</i>. For instance,
+ our Apache package has 55 boolean options. This allows you
+ (theoretically) to build 2^55 = 36,028.797,018.963,968 different
+ binary RPMs out of a single source RPM. There is always one
+ combination which fits your situation well. A binary package has no
+ more possibilities, it just was built for a fixed combination of
+ options. And we doubt that neither a simple "no options enabled" nor
+ an "all options enabled" Apache binary module would be sufficient for
+ our community.
+ <p>
+ <li>Security: even with package signing by the OpenPKG project, from a
+ security paranoia point of few, one never can really just
+ trust a package -- neither a source nor binary one. For real
+ security, every piece of software has to be audited, or at
+ least be auditable. Source packages make this possible, binary
+ packages make this completely impossible except you are trying
+ to perfect the art of disassembling object code and reviewing
+ complex algorithms on assembly layer.
+ </ul>
+</faq>
+
+<faq id="noarch"
+ title="Why aren't there any architecture independent OpenPKG binary RPMs?">
+ As <a href="#source-focus">the previous answer</a> explained,
+ OpenPKG by design focuses on source RPMs and the building and
+ installing directly from them. Binary RPMs are just an intermediate
+ and temporary result in this approach. Binary RPMs make too
+ much trouble and so we try to reduce their issues and not to
+ add extra organisational complexity by the introduction of
+ architecture independent packages. Hence we do not distinguish
+ between architecture independent and dependent binary packages.
</faq>
</ol>
@@ .
______________________________________________________________________
The OpenPKG Project www.openpkg.org
CVS Repository Commit List [EMAIL PROTECTED]
