##
## faq.txt
##

#  ------------------------------------------------------------------------

I: about
T: About OpenPKG

I: why-openpkg
Q: Is OpenPKG useful for me?
A: When you install and maintain many Unix machines or when you are doing
   that job in a team of engineers then OpenPKG is useful for creating
   consistent configurations. If you just maintain one or two servers,
   OpenPKG is usually not worth the effort and you are advised to use vendor
   packages only.

I: about-logo
Q: Is there background information available on the project name and logo?
A: Yes, "OpenPKG" (pronounced "open-pee-kay-chee") is short for "Open
   Source Software Packages". And the logo shows a package containing
   soft pieces of cotton wool. This represents a package of soft ware
   and so symbolically stands for the term "software package". The
   idea and its symbol were invented by Ralf S. Engelschall in April
   2001. He also painted the OpenPKG logo and created the corresponding
   website design.

#  ------------------------------------------------------------------------

I: rpm
T: OpenPKG and RPM

I: why-rpm
Q: Why is RPM used and not any other packaging tool?
A: We evaluated lots of existing software building and packaging
   tools like Debian's dpkg/apt pair, the FreeBSD's ports and their
   companion pkg_xxx(1) tools, the RedHat Package Manager (RPM), the
   SVR4 pkgxxx(1) tool set, the Encap Package Manager (epkg), Ralf S.
   Engelschall's Build'n'Play (BnP) facility, GNU Stow, Opt-Depot and
   various other facilities and tools.
   <p/>
   But to be honest, these tools do not satisfy the requirements of an
   OpenPKG like system.
   <p/>
   Writing a new packaging tool from scratch was not an option, because
   it would have required too much time and it was not clear whether
   we would have been really more successful than others. Instead we
   picked the solution which provided for all(!) of our essential
   wishes a good or at least reasonable solution. The RedHat Package
   Manager (RPM) version 4 is not a perfect solution, but even with its
   drawbacks and pitfalls it fulfills the fundamental needs of OpenPKG.
   One of the most important need was that the tool has to support
   the whole(!) life cycle of a package.

I: vendor-rpm
Q: Can I use both the OpenPKG and my vendor RPM at the same time?
A: Yes, you can. It might even be necessary, as our RPM tool provides a
   different set of functionality as the traditional one. Unfortunately, both
   use the same program name <tt>rpm</tt>. Pay attention to the program paths
   when choosing to operate on the OpenPKG repository or a traditional RPM
   populated one. In any case, do not panic. You cannot accidentally apply the
   wrong RPM tool, because OpenPKG RPM specifications do not work with other
   vendors' implementations. Such other implementations of RPM lack the
   virtual "OpenPKG" pre-requisite definition (which is provided by the
   OpenPKG bootstrap package only). Using other vendor RPM specifications
   with the OpenPKG RPM tool usually works, but stores installation data in
   the wrong RPM database. This is really the only problem to watch out for.
   It is good practice to put your vendor <tt>rpm</tt> tool first in the
   <tt>$PATH</tt>, and call the <tt>rpm</tt> of OpenPKG through an absolute
   path. 

I: no-reuse-vendor-rpm
Q: Why is an OpenPKG specific RPM used even if most 
   Linux distributions already come bundled with it?
A: There are various reasons for this. With our own implementation of RPM,
   the OpenPKG filesystem hierarchy can achieve a high degree of independence
   and furthermore be self-contained. A second reason involves flexibility,
   and only with a custom made RPM can we adjust RPM to truly meet the needs
   of a OpenPKG system. Finally, with our own RPM we can take a consistent
   approach to installations over all supported platforms. Using the vendor
   RPM on Linux, and another on Solaris and FreeBSD was not acceptable for us.

I: single-rpm
Q: OpenPKG requires RPM on all target systems, but lots of sys-admins
   want to stick with the vendor packaging system whenever possible so that only
   a single install tool needs to be learned.
A: This is not really an issue for OpenPKG, because OpenPKG is
   intended for sys-admins who have to manage a <i>large</i> set of
   <i>diverse</i> Unix platforms. So, they are already forced to use
   multiple tools. OpenPKG's RPM might be one more such tool, but
   OTOH it now allows him to redirect most of his daily tasks to only
   <i>this</i> tool. Additionally, for the daily standard tasks of a
   sys-admin, RPM is very easy to use.

I: openpkg-rpm-with-vendor-rpm
Q: Can I use your source RPM packages with a plain RPM v4 environment?
A: No, because our source RPM packages depend on RPM extensions which are not
   available with the plain RPM v4. For example, a plain RPM v4 does not
   supply the <tt>rpmtool</tt> and <tt>shtool</tt> programs. Additionally it
   will fail during any reference to our <tt>%{l_xxx}</tt> variables.

I: vendor-rpm-with-openpkg-rpm
Q: What do I have to change if I want to use a source RPM from another
   vendors with OpenPKG?
A: This is a sensible question and not easy to answer.  In contrast to lots
   of RPM-based (Linux) distributions, OpenPKG did not take over existing
   source RPMs from other vendors (like RedHat or SuSE, etc) at all. OpenPKG
   is a from-scratch clean-room implementation of a packaging system. And
   except for the fact that OpenPKG uses the RPM tool, it does not share
   anything with other RPM-based systems.
   <p/>
   This approach certainly caused us lots of trouble in the beginning
   and required lots of extra efforts, but it was important to follow
   in order to achieve the requirements we had on OpenPKG. Mainly
   this was that the packaging has to be clean (style), minimal
   (redundancy), portable (dependencies) and flexible (hard-coded
   things). So we decided to start entirely from scratch (except for
   the RPM tool) and not to be confused or influenced by existing RPM
   specifications. And experience showed that this was a good decision,
   although it is not shared by lots of people (especially those who
   dislike re-invention of wheels and want to quickly have a solution).
   <p/>
   So, we really advice you to not take over entire RPM specifications.
   Nevertheless (as long as the license on this specification permits
   it), you can try to help yourself by taking over ideas and the
   roadmap for packaging a particular product.
   <p/>
   But if you still insist on reusing a source RPM of another vendor
   with OpenPKG, here are the steps:
   <p/>
   <ul>
   <li>OpenPKG packages have to build-able as non-root for security and
       OS-trashing reasons. So you have to force the underlying vendor
       procedures to build and install in this situation. This mainly means
       that the install procedure is not allowed to chown or chgrp any files.
       This has to be first skipped and later emulated with
       <code>%attr</code> in <code>%files</code>.
   </li>
   <li>OpenPKG packages have to be independent of the filesystem root
       directory of the OpenPKG instance. This means that all packages have
       to be configured, build and rolled for <tt>%{l_prefix}</tt>.
       This mainly means that you are not allowed to use any hard-coded
       root paths.
   </li>
   <li>OpenPKG packages have to comply to the OpenPKG filesystem layout
       standard ("name" is the package name, given are directories only): 
       <tt>%{l_prefix}/bin/</tt> for user binaries; 
       <tt>%{l_prefix}/sbin/</tt> for system administrator binaries;
       <tt>%{l_prefix}/etc/name/</tt> for the configuration files;
       <tt>%{l_prefix}/share/name/</tt> for the constant (read-only) data files;
       <tt>%{l_prefix}/var/name/</tt> for the variable (read/write) data files;
       <tt>%{l_prefix}/libexec/name/</tt> for the internal binaries;
       <tt>%{l_prefix}/man/manN/</tt> for the manual pages;
       <tt>%{l_prefix}/lib/</tt> for the C libraries;
       <tt>%{l_prefix}/include/</tt> for the C headers.
   </li>
   <li>OpenPKG packages have to be build inside <tt>$RPM_BUILD_ROOT</tt>
       for correct file determination and OS-trashing reasons. So you have to
       force the underlying vendor install procedure to install into
       <tt>$RPM_BUILD_ROOT%{l_prefix}</tt> instead of
       <tt>%{l_prefix}</tt>, although it still was configured and built for
       <tt>%{l_prefix}</tt>. This mainly means you have to use
       the <tt>DESTDIR</tt> and/or <tt>prefix</tt> variables on
       <tt>make install</tt>. If all things fail, you have to
       patch the <tt>Makefile</tt> between <tt>make</tt> and
       <tt>make install</tt> or even have to install manually.
   </li>
   <li>OpenPKG packages have to roll the binary package via <tt>%files -f
       files</tt>, i.e., through a <tt>$RPM_BUILD_ROOT</tt>-generated files list.
       This is accomplished by running <tt>rpmtool files</tt> at the end of
       <tt>%install</tt>. But it especially requires the previous point.
   </li>
   </ul>
   <p/>
   Writing conforming packages from scratch usually takes much less effort
   and time than the alternative approach of adjusting a not conforming one.

I: package-type
Q: What are physical/virtual/replacement/alternative packages?
A: In OpenPKG, there are three distinct types of packages when
   it comes to provided package targets for package dependencies:
   <p/>
   <pre>
                                                Virtual Target
                                        ------------------------------------
   RPM Package          Physical Target Name           Existence Type
   -------------------- --------------- -------------- --------- -----------
    foo-VER-REL.src.rpm foo  = VER-REL  <i>none</i>           never     -
   fooX-VER-REL.src.rpm fooX = VER-REL  <b>foo = VER-REL</b>  optional  replacement
    bar-VER-REL.src.rpm bar  = VER-REL  <b>FOO</b>            always    alternative
   </pre>
   <p/>
   As, you can see, every RPM package implicitly provides a <b>physical</b>
   target which directly corresponds to its particular name, version
   and release. Additionally, a package can provide zero or more
   so-called <b>virtual</b> targets. There are two strictly distinct
   instances of a virtual target:
   <p/>
   <ul>
      <li>The virtual target "<tt>FOO</tt>" (<b>without</b> any version and
          release and with the name in <b>uppercase</b> letters only) is used
          by <b>alternative</b> packages. Those packages usually do
          <b>not</b> also have the name "<tt>foo</tt>".
          <p/>
          This virtual target is for <b>automatically handled</b>
          package <b>alternatives</b>. All packages providing this
          target <b>have</b> to conflict by default, because they are
          true alternatives.
          <p/>
          The intention is that those packages are fully equal and
          compatible from the semantical point of view of the virtual target
          and <b>any can be chosen and used</b>. <b>All are supported</b>
          and exists for regular usage.
          <p/>
          Having multiple those packages providing this virtual target is a
          <b>permanent</b> solution and will remain in the long-term.  All
          those packages are usually based on <b>different</b> vendor
          products.
          <p/>
          The classical example is the virtual target "<tt>MTA</tt>",
          provided by the packages "<tt>sendmail</tt>", "<tt>postfix</tt>",
          "<tt>exim</tt>", "<tt>ssmtp</tt>", etc.
      </li>
      <li>The virtual target "<tt>foo = VER-REL</tt>" (<b>with</b> version and
          release and with the name in <b>lowercase</b> letters only) is
          used by <b>replacement</b> packages. Those packages are all
          required to have the name "<tt>fooX</tt>" where "X" is the
          compressed major version string not longer than 2 or 3 digits.
          <p/>
          This virtual target is for <b>manually enforced</b> package
          <b>replacement</b>. All packages providing this target do
          <b>not</b> have to conflict by default, because they are package
          variants which sometimes can coexist. But the "<tt>fooX</tt>"
          packages often can be enforced (by convention through the build
          option "<tt>with_foo yes</tt>") to fake the "<tt>foo</tt>" package
          in order to replace it.
          <p/>
          The intention is that those packages are fully equal and
          compatible from the semantical point of view of the virtual
          target, but although <b>any can be chosen</b>, only <b>one should
          be used</b> (<tt>foo</tt>). Only <b>one is supported</b>
          ("<tt>foo</tt>") and exists for regular usage, while the others
          ("<tt>fooX</tt>") exists for temporary backward compatibility,
          upgrade preparation or bleeding edge testing reasons only.
          <p/>
          Having multiple those packages providing this virtual target is a
          <b>temporary</b> solution and will certainly change in near
          short-term. All those packages are usually based on the
          <b>same</b> vendor product.
          <p/>
          The classical example is the virtual target "<tt>gcc =
          VER-REL</tt>", provided by the packages "<tt>gcc</tt>",
          "<tt>gcc32</tt>", "<tt>gcc34</tt>", etc.
      </li>
   </ul>

I: source-focus
Q: Why does OpenPKG focus on source RPMs only?
A: 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.
     </li>
     <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.
     </li>
     <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.
     </li>
   </ul>

I: noarch
Q: Why aren't there any architecture independent OpenPKG binary RPMs?
A: 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 organizational complexity by the introduction of
   architecture independent packages. Hence we do not distinguish
   between architecture independent and dependent binary packages.

#  ------------------------------------------------------------------------

I: registry
T: OpenPKG Registry

I: what
Q: What is it?
A: A place to register the identities of OpenPKG fellow users and
   installed OpenPKG instances.

I: why
Q: Why was it established?
A: After changed environmental conditions during 2005,
   the OpenPKG Project finally needs to become
   more closely acquainted with its effective user community.

I: problem
Q: What is the real problem about not knowing the users?
A: OpenPKG technically is already a rather large
   Open Source project and with still only very limited manpower
   resources. For providing some services like security updates for
   older releases, reducing or increasing release cycles, making
   release engineering decisions, etc., it is absolutely essential to
   <i>first</i> know who are our users, how much users we have and what
   OpenPKG releases they are actually using. Without first knowing this
   information we can neither afford continuing all of the current
   services nor even providing additional services.

I: mandatory
Q: Wouldn't it be sufficient to ask users for their feedback through non-mandatory mechanisms?
A: Unfortunately, no. We tried this for over five
   years with the <a href="http://www.openpkg.org/feedback.html">Community Feedback</a>
   form but even after five years and multiple calls for feedback we
   just received about 30 feedbacks in total.

I: price
Q: What is the price for fellowship?
A: Lost anonymity. Message resources. Not money.

I: gain
Q: What do I gain with a fellowship?
A: Access to additional download resources.

I: how
Q: How do I register as a fellow user?
A: Post your E-Mail address and receive an activation link.

I: form
Q: Where is the signup form?
A: Signup is integrated into the login under "Account Enrollment".

I: change-password
Q: How do I change my password or fullname?
A: Sorry, still not implemented. Will be available soon.

I: unregister
Q: How do I unregister as a fellow user?
A: Sorry, still not implemented. Will be available soon.

I: password-storage
Q: I'm paranoid. How do you store my password?
A: We're paranoid, too. The whole website authentication is handled
   by OSSP ase (Affiliation Service Environment), running under HTTPS
   only. This way your clear text password is transferred encrypted
   to the registry.openpkg.org website. Then it is immediately hashed
   with the one-way functions MD5, SHA1, crypt/MD5 and crypt/DES and
   stored into the underlying database without any further logging or
   manipulation. You can review this Open Source implementation under <a
   href="http://cvs.ossp.org/ossp-pkg/ase/">http://cvs.ossp.org/ossp-pkg/ase/</a>.
   Nevertheless, for security reasons please do not reuse any
   existing password.

I: unable-login
Q: I registered, but I'm unable to login?
A: Your registered email address is treated case-sensitive, so make sure
   you specifiy it on login exactly as you did when registering.

#  ------------------------------------------------------------------------

I: download
T: OpenPKG Download Service

I: invisible-files
Q: Certain files on the OpenPKG FTP server are invisible or missing!
A: Signup as a fellow user for free and use your identity when logging in.

I: rpm-rebuild
Q: Certain commands like "rpm --rebuild" fail on ftp.openpkg.org addresses!
A: Signup as fellow user, register the instance and associate it to you.

I: restrict-foss
Q: Why do you restrict the download of Open Source software? Is this compliant with FOSS?
A: We do not really restrict the download of our software. 
   Everyone still can download all of our resources and fully free
   of charge. He just has to identify. What we restricted is the
   <i>anonymous</i> download of some more expensive parts of our
   software as it really hurts the project. FOSS is mainly about freedom
   in the meaning of non-discrimination of users and the possibility
   to review the source code. For OpenPKG and its extremely liberal
   BSD-style distribution license it is even a lot more, too. But FOSS
   is not about anonymity.

I: how-many-files
Q: How many files are restricted under anonymous access?
A: Currently we have 65GB of distribution data and 44GB of them are
   restricted for anonymous access.

I: using-password
Q: Do I have to use my OpenPKG Registry password for acccessing the FTP and RSYNC service?
A: NO! Please don't use this password for downloading. It would be
   transferred in clear text due to the FTP protocol design. Instead use an
   arbitrary password, including the preferred empty one.

I: arbitrary-password
Q: Why can an arbitrary password be used? This allows abuse.
A: Yes, but the login intentionally is for identification only, not
   authentication. If someone uses a foreign identity he just hurts
   himself, because he is not known and this way not taken into account by
   the OpenPKG project.

I: foss-mirror
Q: OpenPKG is Free and Open Source Software (FOSS) and anybody can
   establish a public mirror anyway, right?
A: Yes, if somebody prefers full anonymity he can
   download from an (unfairly but fully legally) established mirror of
   the restricted download files. We fully believe in the seriousness,
   fairness and support of our user community and hence not actively
   using any existing public mirrors when downloading
   restricted files. Instead every serious OpenPKG user is called to
   actively support the OpenPKG project by identifying and downloading from the
   official distribution source location or using a private mirror only.

I: ftp-login-username
Q: What is the correct username for FTP login?
A: Use the fellow E-Mail address. In a FTP URL the "@" needs to be
   replaced by "%40" in some clients.

I: ftp-login-password
Q: What is the correct password for FTP login?
A: Anything works. It is currently not checked as the OpenPKG registry
   is about tracking, not security.

I: rsync-login-username
Q: What is the correct username for RSYNC?
A: Use the fellow E-Mail address. RSYNC supports multiple "@" in the
   URL. See example below.

I: example-ftp-access
Q: Can you give an example FTP access?
A: <tt>ftp://<i>johndoe@example.com</i>:@ftp.openpkg.org/</tt>

I: example-rsync-access
Q: Can you give an example RSYNC access?
A: <tt>RSYNC_PASSWORD="" rsync rsync://<i>johndoe@example.com</i>@rsync.openpkg.org/openpkg-ftp/</tt>

#  ------------------------------------------------------------------------

I: openpkg-instance-registration
T: OpenPKG Instance Registration

I: register-instance
Q: How do I register an installed OpenPKG instance?
A: Install the "openpkg-registry" package from OpenPKG-CURRENT and run "openpkg register".

I: register-interactive
Q: The "openpkg register" is interactive by default? Can I do it in batch?
A: Yes, run "openpkg register --mode=post --user=<i>email-address</i>"

I: associate-instance
Q: How do I associate the OpenPKG instance to my fellow account?
A: Login to the registry and open the "association" page.

I: automated-association
Q: Why isn't it possible to easily automate the association process?
A: This is intentional by design as it enforces users to visit the website from time to time, allowing the OpenPKG project to stay in touch with them.

I: unregister-instance
Q: How do I unregister an installed OpenPKG instance from the registry?
A: Find the instance in the association table, select it and press DEL.

I: disable-url-rewriting
Q: How do I unregister an installed instance locally, disabling the URL rewriting?
A: run "openpkg register --mode=wipe".

I: paranoia
Q: I'm a little bit paranoid. What information is transferred to the OpenPKG Registry?
A: At the cost of increasing the complexity we made the instance registration really ultra-transparent if wished.
   See especially the $prefix/etc/openpkg/registry.prep file for details what is posted online. It contains no
   really sensitive personal information.

#  ------------------------------------------------------------------------

I: misc
T: MISC

I: os-support
Q: Why are only the operating systems Solaris, Linux and
   FreeBSD fully supported?
A: To begin with, OpenPKG works on a number of other Unix variants. It
   can further be patched with small changes to work on an even larger
   set of Unix variants. However, we promise full support only to
   Solaris, Linux and FreeBSD users because they are the most popular
   server platforms.
   OpenPKG will run just as well on many other operating systems,
   however. These additional platforms are not fully supported only
   because the resources needed to ensure correct package builds at
   OpenPKG central are not sufficient. To find out more about how well
   OpenPKG will likely run on your platform, please refer to <a
   href="http://www.openpkg.org/doc/handbook/openpkg.html#support-official">OpenPKG
   handbook</a>

I: no-nls
Q: Why is there no Native Language Support (NLS) in OpenPKG packages?
A: There are many reasons why even packages which are shipped with NLS
   support are not packaged with NLS support. First, NLS is great if
   the whole system, i.e., all packages, provide NLS support. But this
   is not the case for OpenPKG, because unfortunately still not all
   vendors support NLS in their programs. So OpenPKG cannot provide NLS
   for them as a whole, and a half solution was not acceptable to us.
   <p/>
   Second, we dislike the bloat gettext-based NLS support causes on
   the filesystem for each package, because in OpenPKG we try to strip
   down a package to its bare minimum. Third, although the founders of
   OpenPKG are non-native English speakers, they like the idea that
   English was and should be kept as the only language used by Unix
   systems. This further ensures against strange translated messages
   which often serve to confuse rather than aid an engineer.
   <p/>
   In a perfect world all vendor packages would ship with the same
   amount of NLS support (number of supported languages). All
   translations would be done correctly and consistently. Filesystems
   would not bloat from hundreds of extra files for each program just
   because it is localized to hundreds of languages. We as OpenPKG
   enthusiasts are patiently waiting for this dream world to appear,
   and will then provide OpenPKG with fully NLS support, of course. But
   until this happens, we think it is better to avoid NLS entirely. We
   extend our sympathy to those who prefer a non-English language even
   on computers.

I: openpkg-vs-unix
Q: OpenPKG breaks with a few things from the good old Unix days. Why?
A: Maybe you are thinking of the OpenPKG run-command (RC) system or the
   fact that tools and configuration files sometimes are located
   at unusual filesystem paths.
   <p/>
   The implemented run-command facility is partly modeled after the
   classical UNIX(tm) System V run-command facility plus ideas taken
   from the FreeBSD and NetBSD run-command facilities. It mainly
   merges the classical startup/shutdown procedures with periodical
   procedures into a single approach. For details read "openpkg man
   rc". The common task of log file rotation is explained in
   "openpkg man shtool-rotate" with the man page being part of the
   shtool package. In general OpenPKG follows the philosophy "keep it
   simple, stupid" (KISS) and "principle of least astonishment" (POLA).
   If something can be done more orthogonally then OpenPKG prefers the
   consistent and clean approach in favor following administrative habits. Some
   de-facto standards had to be broken as result of creating the unique
   multi-instance feature of OpenPKG.

I: know-how
Q: What do I have to know for a successful deployment?
A: You need to understand some basics about RPM usage, the OpenPKG
   filesystem layout, the shell environment and the run-command
   facility. The <a href="tutorial.html">User Tutorial</a> and the
   <a href="doc/quickref/openpkg.txt">Quick Reference</a> are good
   starting points to gain that knowledge.

I: no-shlib
Q: Why is everything in OpenPKG statically linked? On modern Unix
   platforms, the philosophy is to dynamically link everything.
A: A clarification: in OpenPKG executables are dynamically linked against
   operating system (external) libraries, of course. What you are talking
   about is the linking against the OpenPKG provided (internal) libraries.
   These are currently build as static libraries (<tt>.a</tt>) instead of
   shared libraries (<tt>.so</tt>) for various reasons.
   <p/>
   We use static linking for them mainly to avoid cross-platform trouble.
   Because with shared libraries you have to fiddle around with
   <tt>LD_LIBRARY_PATH</tt> (and/or <tt>ldconfig</tt> if existing) and
   especially can run into trouble for libraries which the OS vendor also
   provides (examples are <tt>libdb</tt>, <tt>libz</tt>, etc). In using only
   static linking inside OpenPKG we are a little bit less flexible and our
   object code grows in size, but OTOH we already avoid lots of trouble in
   advance.
   <p/>
   Nevertheless we certainly will try to change this after some settlement of
   OpenPKG. At least it is on our wishlist for forthcoming OpenPKG
   releases. So it certainly can be changed, but we have to evaluate first
   and make sure we do not open a can of worms related to the cross-platform
   aspect. 

I: no-vcheck
Q: I see that the packages of OpenPKG-CURRENT are updated very fast,
   sometimes even before the announcement on Freshmeat can be seen.
   How is this achieved?
A: The OpenPKG team uses a fully automated process for tracking vendor source
   versions which reports to the team twice per day the list of packages
   which need to be updated. Additionally, there is always the job of a
   Package Master On Duty (PMOD) assigned to a person which trys to
   immediately perform this update on a daily basis. This way OpenPKG-CURRENT
   packages are kept always up-to-date for our community as fast as possible
   and this way we are able to get feedback as early as possible.

I: no-current
Q: I recognize that packages of OpenPKG-CURRENT are sometimes broken
   on Linux or Solaris, but usually never on FreeBSD?
A: The primary development platform, where the Package Master On
   Duty (PMOD) performs his daily tasks, is FreeBSD. Because of time
   constraints the PMOD after an OpenPKG-CURRENT package upgrade only
   tests it also on Linux and Solaris if time permits. If time does not
   permit it, the brokenness is discovered later only. But it is at last
   discovered before an official OpenPKG release because there are all
   involved packages tested in depth, of course.

I: num-pkgs
Q: Compared to the 11000 packages in FreeBSD and 15000 packages in Debian GNU/Linux
   the 950 packages OpenPKG provides look rather tiny?
A: If you compare just the number of packages, this is correct. 
   But you are comparing apples with pears here, because:
   <p/>
   <ol>
     <li>FreeBSD and Debian usually package <i>everything</i>, although
     90% of the packaged software are just neat toys and far away from
     killer applications. OpenPKG is the other way round: 90% are
     formed by essential packages only and just the remainder are toys.
     </li>
     <li>FreeBSD and Debian provide packaged software for all types
     of deployment, ranging from stripped-down embedded devices, over
     networking servers, up to colorful desktops with all bells and
     whistles. OpenPKG mainly focuses on deployment on network servers
     and up to now has just a few desktop-related packages. If you
     really want to deploy software in non-server situations you should
     not focus on OpenPKG, please. Then please stick with the packages
     of other vendors which focus on your situation.
     </li>
     <li>FreeBSD and Debian usually package all variants, versions and
     alternatives of a piece of software. For instance, they provide
     dozens of possible shells while OpenPKG mainly just provides the
     most popular ones (bash, ksh, tcsh, zsh). Additionally, they
     package very often multiple vendor versions (stable, development,
     snapshot, etc) while OpenPKG most of the time provides only a
     single version.
     </li>
   </ol>
   <p/>
   All those points together result in the dramatically different
   numbers of packages. But it is wrong if you think the lower number of
   packages would mean OpenPKG is incomplete. OpenPKG actually provides
   far more packages for software than you usually need to deploy on a
   server platform.

I: entry-points
Q: What will the bootstrap procedure (as root user) do to my system?
A: The bootstrap procedure has only one purpose, and that is to install a new
   OpenPKG instance. Remember that the procedure accomplishes this in two
   stages. The first stage can be run as any user and mostly builds the tools
   that OpenPKG needs (tar, shtool, bunzip...). The second part needs to be
   run as root however, and will alter the underlying system. Admins running
   intrusion detection should take note. The five entry points are:
   <p/>
   <ol>
      <li>Users and groups are added to /etc/passwd and /etc/group, or
          whichever default mechanism the corresponding platform supports.
      </li>
      <li>Crontab entries are made (typically to /etc/crontab) to allow
          subsequent OpenPKG packages to operate periodically.
      </li>
      <li>An init script (typically at /etc/init.d/&lt;prefix&gt;) is added to
          start all active daemons and other OpenPKG packages at system
          startup. Remember that packages can always be 'deactivated' and
          started or stopped manually as well.
      </li>
      <li>OpenPKG 2.0 and later log their prefix into file
          /etc/openpkg. This allows inventory mechanisms to find
          all instances installed on a machine.
      </li>
      <li>Naturally, OpenPKG will take space in the file system corresponding
          to the prefix given during the first bootstrap stage.
      </li>
   </ol>
   <p/>
   Curious admins can learn more about these entry points by comparing the
   system before and after bootstrapping a new OpenPKG instance. In each
   case, the bootstrap procedure uses the information given (--prefix,
   --user, --group, [--rusr]...), so finding any system alterations should be
   easy.

I: deinstallation
Q: How clean or dirty will my system be after a full deinstall?
A: To deinstall OpenPKG, simply remove the package called 'openpkg' in the
   same way that any other package is removed (/prefix/bin/rpm -e openpkg).
   If any dependent package exists, OpenPKG will require that it first be
   removed.
   <p/>
   Once the deinstallation finishes, the system will return to its initial
   state. Any exceptions to this rule are due to files manually installed or
   others inhibiting the removal of the complete file hierarchy. This is
   desirable due to the preservation of log files, for example.
   <p/>To verify this, an admin can compare the system (by copying files
   associated to the entry points above) before and after bootstrapping
   OpenPKG to confirm this (de)installation consistency.

I: porting
Q: How can I port OpenPKG to a new platform?
A: Porting OpenPKG to a new platform usually is two-fold:
   <ol>
      <li>You have to get the bootstrap package "openpkg" building and
          running on the new platform. This basically means that that the
          contained software packages (Bash, cURL, Tar, RPM, etc) have to
          build and that the linking into the system (users/groups and
          cron/init scripts) is known by the bootstrap. For getting the
          software building, you perhaps have to add one or more patchfiles
          to the "openpkg" package or at least use some "shtool"
          substitutions in "openpkg.spec". For the linking into the system,
          add the corresponding commands to the "%pre" and "%preun" sections
          of "openpkg.spec".
      </li>
      <li>You have to port your wished OpenPKG packages to the new platform.
          Because all OpenPKG packages are inherently portable (because
          do not contain any platform specific things), porting them
          usually always means to get the underlying vendor software
          package building. OpenPKG most of the time (only a few exceptions
          exists) package only already portable vendor software. So
          as long as your new platform provides a fair amount of the POSIX
          APIs, mostly all OpenPKG packages will work out of the box.
          For the remaining packages, you have to add a patch file
          to the package which fixes your particular platform problems.
      </li>
   </ol>

I: uid-security
Q: What is the fuzz about those multiple user/group ids in OpenPKG?
A: Starting with OpenPKG 1.1, the bootstrapping package ("openpkg") uses
   four distinct Unix user/group id pairs (previous versions used only two).
   <p/>
   <pre>
   Name             Option RPM-Macro Default       Example Files Proc.
   ---------------- ------ --------- ------------- ------- ----- -----
   super user       --susr %{l_susr} root          root    some  some    
   super group      --sgrp %{l_sgrp} groupof(susr) wheel   some  some    
   managing user    --musr %{l_musr} &lt;user&gt;        opkg    most  none    
   managing group   --mgrp %{l_mgrp} &lt;group&gt;       opkg    most  none    
   restricted user  --rusr %{l_rusr} &lt;user&gt;-r      opkg-r  some  some    
   restricted group --rgrp %{l_rgrp} &lt;group&gt;-r     opkg-r  some  some    
   nobody user      --nusr %{l_nusr} &lt;user&gt;-n      opkg-n  none  most    
   nobody group     --ngrp %{l_ngrp} &lt;group&gt;-n     opkg-n  none  most    
   </pre>
   <p/>
   The default values are derived from the options
   <tt>--user=&lt;user&gt;</tt> and <tt>--group=&lt;group&gt;</tt>
   on the command line of <tt>openpkg-*.src.sh</tt>. For instance,
   the "Example" values above are achieved with <tt>--user=opkg
   --group=opkg</tt>. In case of a non-privileged OpenPKG instance,
   the {mrn}{usr,grp} are usually identical.
   <p/>
   For security reasons it is important to treat at least the "managing
   user/group" equal to the "super user/group", similar to what has
   to be done with the usual Unix "root" and "bin" user/group ids.
   The reason mainly is that the "super user/group" executes files
   intentionally owned by the "managing user/group".
   <p/>
   Similarly the "restricted user/group" and "nobody user/group"
   have to be treated like the usual Unix user/group id "nobody" with
   the addition that the OpenPKG "restricted user/group" has little
   bit more privileges than the "nobody user/group" because (mostly
   generated) files are also owned by him.
   <p/>
   Find more about this topic in the
   <a href="/doc/handbook/openpkg.html#security-usergroup">Handbook</a>.

I: uid-query
Q: How can i query OpenPKG RPM to see which user/group names/ids are used?
A: <pre>
   for i in s m r n; do
       rpm --eval "${i}usr=%{l_${i}usr}, ${i}grp=%{l_${i}grp}"
       rpm --eval "${i}uid=%{l_${i}uid}, ${i}gid=%{l_${i}gid}"
   done</pre>

I: overriding-cflags
Q: How can i override the CFLAGS default for all packages?
A: You can override the RPM default of <tt>%l_cflags</tt> permanently in your
   <tt>~/.rpmmacros</tt>. Example:
   <p/>
   <pre>%l_cflags -pipe -O3 -march=i686 -funroll-loops</pre>

I: overriding-cc
Q: How can i override the CC default for all packages?
A: You can override the RPM default <tt>%l_cc</tt> permanently in your
   <tt>~/.rpmmacros</tt>. This is especially useful when bootstrapping
   platforms where OpenPKG does not initially find a C compiler in the
   path. The most prominent example is Solaris. Example:
   <p/>
   <pre>%l_cc    /usr/local/bin/gcc</pre>
   <p/>
   Alternatively, you can override <tt>%l_cc</tt> for a single rebuild
   by defining "use_cc".
   <p/>
   <pre>openpkg rpm --define "use_cc /usr/local/bin/gcc" --rebuild ...</pre>

I: perl-gcc
Q: Why does perl require gcc at run-time?
A: The build-time of a module with XS parts is the run-time of Perl.
   Those modules require <b>exactly</b> the C compiler at their
   build-time which was previously used at the built-time of "perl".
   To control C compiler usage in a deterministic way both at "perl"
   build-time and module build-time aka Perl run-time the "perl"
   package has "gcc" listed as both a <tt>BuildPreReq</tt> and a
   <tt>PreReq</tt>.

I: update-where
Q: Where can i find packages and information about updates within a release?
A: Find updated packages for releases in the UPD directory below
   the release on the <a href="ftp://ftp.openpkg.org/release/">FTP
   Server</a>. Find a brief description for each update
   in the 00README file beneath the package.
   Example: <a href="ftp://ftp.openpkg.org/release/1.3/UPD/00README">
   release/1.3/UPD/00README</a> file. Find in-depth developer level
   information by browsing the CVS timeline of the package.
   Example: <a href="http://cvs.openpkg.org/timeline?px=openpkg-src/openssh">
   OpenSSH</a>.

I: update-breakexisting
Q: Will updating a package within a release likely break my existing setup?
A: While we cannot guarantee this won't it is very unlikely that
   an update will break an existing setup. In fact, one reason
   why updates are created is to fix existing problems in the
   least intrusive and most compatible way. Updates will always
   include the same vendor version. Sometimes we even preserve bugs
   intentionally. Most updates are driven by security incidents
   which come with an advisory describing the problem, scope and
   required actions to prevent the problem. Please examine our <a
   href="http://www.openpkg.org/security.html">security pages</a>. In
   any case we work hard to make upgrades a no-brainer. Packages are
   designed to be drop-in replacements for it predecessor(s).

I: update-mutliple
Q: What should i do if multiple updates within a release exist?
A: Our updates are patched full packages. Just take the latest.