head 1.48; access; symbols INITIAL:1.1.1.1 VENDOR:1.1.1; locks; strict; comment @# @; 1.48 date 2005.09.21.13.18.29; author cs; state Exp; branches; next 1.47; 1.47 date 2005.03.24.13.05.08; author rse; state Exp; branches; next 1.46; 1.46 date 2004.06.02.13.05.49; author ms; state Exp; branches; next 1.45; 1.45 date 2004.03.09.21.12.00; author thl; state Exp; branches; next 1.44; 1.44 date 2004.02.27.15.20.27; author thl; state Exp; branches; next 1.43; 1.43 date 2003.11.28.14.19.19; author thl; state Exp; branches; next 1.42; 1.42 date 2003.11.28.13.46.27; author thl; state Exp; branches; next 1.41; 1.41 date 2003.08.14.17.21.09; author mlelstv; state Exp; branches; next 1.40; 1.40 date 2003.08.07.14.46.09; author thl; state Exp; branches; next 1.39; 1.39 date 2003.07.29.18.52.12; author rse; state Exp; branches; next 1.38; 1.38 date 2003.07.12.19.38.24; author thl; state Exp; branches; next 1.37; 1.37 date 2003.07.12.11.50.04; author rse; state Exp; branches; next 1.36; 1.36 date 2003.04.22.13.55.41; author ms; state Exp; branches; next 1.35; 1.35 date 2003.04.22.13.01.05; author ms; state Exp; branches; next 1.34; 1.34 date 2003.04.22.12.58.03; author ms; state Exp; branches; next 1.33; 1.33 date 2003.04.22.12.55.38; author ms; state Exp; branches; next 1.32; 1.32 date 2003.04.22.12.54.01; author ms; state Exp; branches; next 1.31; 1.31 date 2003.04.22.12.06.48; author ms; state Exp; branches; next 1.30; 1.30 date 2003.04.22.12.05.29; author ms; state Exp; branches; next 1.29; 1.29 date 2003.04.02.15.44.57; author thl; state Exp; branches; next 1.28; 1.28 date 2003.04.02.13.06.00; author thl; state Exp; branches; next 1.27; 1.27 date 2003.04.02.10.04.35; author thl; state Exp; branches; next 1.26; 1.26 date 2003.02.26.08.53.11; author thl; state Exp; branches; next 1.25; 1.25 date 2003.02.26.08.38.14; author thl; state Exp; branches; next 1.24; 1.24 date 2003.02.26.08.18.21; author thl; state Exp; branches; next 1.23; 1.23 date 2003.01.20.18.41.20; author ms; state Exp; branches; next 1.22; 1.22 date 2003.01.15.11.12.26; author ms; state Exp; branches; next 1.21; 1.21 date 2003.01.15.09.07.29; author thl; state Exp; branches; next 1.20; 1.20 date 2003.01.13.16.17.50; author rse; state Exp; branches; next 1.19; 1.19 date 2003.01.13.16.05.51; author rse; state Exp; branches; next 1.18; 1.18 date 2003.01.13.14.34.38; author thl; state Exp; branches; next 1.17; 1.17 date 2003.01.13.14.08.40; author rse; state Exp; branches; next 1.16; 1.16 date 2003.01.13.13.58.21; author thl; state Exp; branches; next 1.15; 1.15 date 2003.01.06.09.52.59; author rse; state Exp; branches; next 1.14; 1.14 date 2002.11.18.16.02.46; author rse; state Exp; branches; next 1.13; 1.13 date 2002.04.04.14.06.32; author rse; state Exp; branches; next 1.12; 1.12 date 2002.01.22.13.44.18; author rse; state Exp; branches; next 1.11; 1.11 date 2002.01.22.13.43.50; author rse; state Exp; branches; next 1.10; 1.10 date 2002.01.18.14.52.02; author rse; state Exp; branches; next 1.9; 1.9 date 2002.01.12.12.11.00; author rse; state Exp; branches; next 1.8; 1.8 date 2002.01.12.11.03.48; author rse; state Exp; branches; next 1.7; 1.7 date 2002.01.11.19.15.11; author rse; state Exp; branches; next 1.6; 1.6 date 2001.12.03.12.15.37; author rse; state Exp; branches; next 1.5; 1.5 date 2001.11.27.14.58.01; author rse; state Exp; branches; next 1.4; 1.4 date 2001.11.27.13.45.01; author rse; state Exp; branches; next 1.3; 1.3 date 2001.11.23.16.00.08; author rse; state Exp; branches; next 1.2; 1.2 date 2001.09.02.10.26.52; author rse; state Exp; branches; next 1.1; 1.1 date 2001.08.28.12.57.50; author rse; state Exp; branches 1.1.1.1; next ; 1.1.1.1 date 2001.08.28.12.57.50; author rse; state Exp; branches; next ; desc @@ 1.48 log @removed dead link to vcheck files @ text @ #use "page.inc" page=faq Frequently Asked Questions (FAQ)

Frequently Asked Questions (FAQ)

This is a list of frequently asked questions and answers about OpenPKG.

  • [A]
    %body
    1. 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. 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.

      But to be honest, these tools do not satisfy the requirements of an OpenPKG like system.

      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. 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 rpm. 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 rpm tool first in the $PATH, and call the rpm of OpenPKG through an absolute path. 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. This is not really an issue for OpenPKG, because OpenPKG is intended for sys-admins who have to manage a large set of diverse 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 this tool. Additionally, for the daily standard tasks of a sys-admin, RPM is very easy to use. 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 OpenPKG handbook 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 rpmtool and shtool programs. Additionally it will fail during any reference to our %{l_xxx} variables. 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.

      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).

      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.

      But if you still insist on reusing a source RPM of another vendor with OpenPKG, here are the steps:

      Writing conforming packages from scratch usually takes much less effort and time than the alternative approach of adjusting a not conforming one. 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.

      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.

      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. Maybe you are thinking of the OpenPKG run-command (RC) system, the fact that in OpenPKG the tools sometimes use non-default filesystem paths, etc. pp?

      This topic may be confusing at first glance. Nevertheless, the decision was taken after a lot of discussions and evaluations. We cannot explain the details of the OpenPKG run-command system here (read the OpenPKG handbook instead), but in general OpenPKG follows the philosophy, "keep it simple, stupid" (KISS) and "principle of least surprise." OpenPKG follows these good practice guidelines except for when something can be done more cleanly and more orthogonally we break with this intentionally. Additionally, sometimes standards had to be broken as result of making OpenPKG a stand-alone and self-contained sub-system. You need to understand some basics about RPM usage, the OpenPKG filesystem layout, the shell environment and the run-command facility. The User Tutorial and the Quick Reference are good starting points to gain that knowledge. 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 (.a) instead of shared libraries (.so) for various reasons.

      We use static linking for them mainly to avoid cross-platform trouble. Because with shared libraries you have to fiddle around with LD_LIBRARY_PATH (and/or ldconfig if existing) and especially can run into trouble for libraries which the OS vendor also provides (examples are libdb, libz, 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.

      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. 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. 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. If you compare just the number of packages, this is correct. But you are comparing apples with pears here, because:

      1. FreeBSD and Debian usually package everything, 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.

      2. 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.

      3. 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.

      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.

      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:

      1. Users and groups are added to /etc/passwd and /etc/group, or whichever default mechanism the corresponding platform supports.

      2. Crontab entries are made (typically to /etc/crontab) to allow subsequent OpenPKG packages to operate periodically.

      3. An init script (typically at /etc/init.d/<prefix>) 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.

      4. OpenPKG 2.0 and later log their prefix into file /etc/openpkg. This allows inventory mechanisms to find all instances installed on a machine.

      5. Naturally, OpenPKG will take space in the file system corresponding to the prefix given during the first bootstrap stage.

      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.

      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.

      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.

      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.

      Porting OpenPKG to a new platform usually is two-fold:

      1. 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".

      2. 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.
      Starting with OpenPKG 1.1, the bootstrapping package ("openpkg") uses four distinct Unix user/group id pairs (previous versions used only two).

      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} <user>        opkg    most  none    
      managing group   --mgrp %{l_mgrp} <group>       opkg    most  none    
      restricted user  --rusr %{l_rusr} <user>-r      opkg-r  some  some    
      restricted group --rgrp %{l_rgrp} <group>-r     opkg-r  some  some    
      nobody user      --nusr %{l_nusr} <user>-n      opkg-n  none  most    
      nobody group     --ngrp %{l_ngrp} <group>-n     opkg-n  none  most    
      

      The default values are derived from the options --user=<user> and --group=<group> on the command line of openpkg-*.src.sh. For instance, the "Example" values above are achieved with --user=opkg --group=opkg. In case of a non-privileged OpenPKG instance, the {mrn}{usr,grp} are usually identical.

      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".

      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.

      Find more about this topic in the Handbook.

      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
      You can override the RPM default of %l_cflags permanently in your ~/.rpmmacros. Example:

      %l_cflags    -pipe -O3 -march=i686 -funroll-loops
      You can override the RPM default %l_cc permanently in your ~/.rpmmacros. 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:

      %l_cc    /usr/local/bin/gcc

      Alternatively, you can override %l_cc for a single rebuild by defining "use_cc".

      .../rpm --define "use_cc /usr/local/bin/gcc" --rebuild ...
      The build-time of a module with XS parts is the run-time of Perl. Those modules require exactly 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 BuildPreReq and a PreReq. In OpenPKG, there are three distinct types of packages when it comes to provided package targets for package dependencies:

                                                   Virtual Target
                                           ------------------------------------
      RPM Package          Physical Target Name           Existence Type
      -------------------- --------------- -------------- --------- -----------
       foo-VER-REL.src.rpm foo  = VER-REL  none           never     -
      fooX-VER-REL.src.rpm fooX = VER-REL  foo = VER-REL  optional  replacement
       bar-VER-REL.src.rpm bar  = VER-REL  FOO            always    alternative
      
           

      As, you can see, every RPM package implicitly provides a physical target which directly corresponds to its particular name, version and release. Additionally, a package can provide zero or more so-called virtual targets. There are two strictly distinct instances of a virtual target:

      • The virtual target "FOO" (without any version and release and with the name in uppercase letters only) is used by alternative packages. Those packages usually do not also have the name "foo".

        This virtual target is for automatically handled package alternatives. All packages providing this target have to conflict by default, because they are true alternatives.

        The intention is that those packages are fully equal and compatible from the semantical point of view of the virtual target and any can be chosen and used. All are supported and exists for regular usage.

        Having multiple those packages providing this virtual target is a permanent solution and will remain in the long-term. All those packages are usually based on different vendor products.

        The classical example is the virtual target "MTA", provided by the packages "sendmail", "postfix", "exim", "ssmtp", etc.

      • The virtual target "foo = VER-REL" (with version and release and with the name in lowercase letters only) is used by replacement packages. Those packages are all required to have the name "fooX" where "X" is the compressed major version string not longer than 2 or 3 digits.

        This virtual target is for manually enforced package replacement. All packages providing this target do not have to conflict by default, because they are package variants which sometimes can coexist. But the "fooX" packages often can be enforced (by convention through the build option "with_foo yes") to fake the "foo" package in order to replace it.

        The intention is that those packages are fully equal and compatible from the semantical point of view of the virtual target, but although any can be chosen, only one should be used (foo). Only one is supported ("foo") and exists for regular usage, while the others ("fooX") exists for temporary backward compatibility, upgrade preparation or bleeding edge testing reasons only.

        Having multiple those packages providing this virtual target is a temporary solution and will certainly change in near short-term. All those packages are usually based on the same vendor product.

        The classical example is the virtual target "gcc = VER-REL", provided by the packages "gcc", "gcc32", "gcc34", etc.

      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:

      • Stability: binary RPMs are inherently weak when it comes to run-time stability. The reason is that there are always 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.

        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.

      • Flexibility: OpenPKG source RPMs often have a bunch of build "options" (can be queried with rpm -qpi) for allowing one to build a package in multiple different variants. 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.

      • 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.
      As the previous answer 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. Find updated packages for releases in the UPD directory below the release on the FTP Server. Find a brief description for each update in the 00README file beneath the package. Example: release/1.3/UPD/00README file. Find in-depth developer level information by browsing the CVS timeline of the package. Example: OpenSSH. 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 security pages. In any case we work hard to make upgrades a no-brainer. Packages are designed to be drop-in replacements for it predecessor(s). Our updates are patched full packages. Just take the latest.
    @ 1.47 log @adjust website for new world order, too @ text @d303 1 a303 2 versions (see here for details) which reports to the team twice per day the list of packages @ 1.46 log @either remove the last HTML list item causing a fifth (the weakest literary) point, or specify that there exist five entry points in total @ text @d124 1 a124 1 server platforms of the customers at Cable & Wireless Germany. @ 1.45 log @mention /etc/openpkg @ text @d369 1 a369 1 intrusion detection should take note. The four entry points are: @ 1.44 log @style and cosmetics @ text @d383 4 @ 1.43 log @add UPD information @ text @d10 6 d22 1 a22 1

    d24 1 d29 1 a29 1

      d442 2 a443 2 Starting with OpenPKG 1.1 the bootstrapping package ("openpkg") uses four distinct Unix user/group id pairs, previous versions used only two. @ 1.42 log @fix link @ text @d666 33 @ 1.41 log @reflect change in macro name (with_cc -> use_cc) @ text @d296 1 a296 1 versions (see here for @ 1.40 log @spell checking and correcting @ text @d506 1 a506 1 by defining "with_cc". d509 1 a509 1 .../rpm --define "with_cc /usr/local/bin/gcc" --rebuild ... @ 1.39 log @one entry obsoleted by OpenPKG 1.3, two new added for answering new things @ text @d172 1 a172 1
    1. OpenPKG packages habe to be independent of the filesystem root d285 1 a285 1 OpenPKG. At least it is on our list of trys for forthcoming OpenPKG 1.x d661 1 a661 1 add extra organisational complexity by the introduction of @ 1.38 log @typo @ text @a432 32 The "openpkg*.src.sh" 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.

      When a user creates a "openpkg-*.arch-os-hierarchy.sh" 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.

      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 "openpkg-*.src.sh" 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. d601 63 @ 1.37 log @cleanup markup, fix typos, add package type FAQ entry @ text @d619 1 a619 1 be used (foo). Only only is supported @ 1.36 log @Add file name for init.d script. @ text @d62 1 a62 1 drawbacks and pitfalls it fulfills the fundemental needs of OpenPKG. d70 1 a70 1 different set of functionality as the traditional one. Unfortunatly, both d73 1 a73 1 populated one. In any case, do not panic. You cannot accidently apply the d158 1 a158 1 it), you can try to help youself by taking over ideas and the d207 2 a208 2 Writing conformant packages from scratch usually takes much less effort and time than the alternative approach of adjusting a nonconformant one. d253 1 a253 1 Additionally, sometimes standards had to breaked as result of making d263 1 a263 1 starting points to gain that knowldege. d271 1 a271 1 about is the linking agains the OpenPKG provided (internal) libraries. d299 1 a299 1 Package Master On Duty (PMOD) assigned to a person which tries to d312 1 a312 1 permit it, the brokeness is discovered later only. But it is at last d355 1 a355 1 title="What will the bootstrap prodedure (as root user) do to my system?"> d392 1 a392 1 If any dependant package exists, OpenPKG will require that it first be d449 1 a449 1 availablity of compress(1) to the user. As described above, the d470 1 d483 1 d498 1 a498 1 Similarily the "restricted user/group" and "nobody user/group" d510 1 d512 4 a515 5 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 d522 1 d524 1 a524 2 %l_cflags -pipe -O3 -march=i686 -funroll-loops d533 1 d535 2 a536 2 %l_cc /usr/local/bin/gcc d539 1 d541 1 a541 2 .../rpm --define "with_cc /usr/local/bin/gcc" --rebuild ... d554 81 @ 1.35 log @Edit mistakes that slipped through prior editing. @ text @d371 4 a374 3

    2. Init scripts are 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. @ 1.34 log @Polish off latest additions by using consistent language - bootstrap procedure and not bootstrap process. @ text @d379 5 a383 4 Curious admins can learn more about these entry points by doing before and after comparisons. In each case, the bootstrap procedure uses the information given (--prefix, --user, --group, [--rusr]...), so finding the system alterations should be very easy. d387 1 a387 1 title="How cleanly or dirty will my system be after a full deinstall?"> @ 1.33 log @Remove unneeded parentheses. @ text @d380 1 a380 1 after comparisons. In each case, the bootstrap process uses the @ 1.32 log @Fix typo. @ text @d361 2 a362 2 run as root however, and will alter the underlying system (admins running intrusion detection take note). The four entry points are: d365 2 a366 2
    3. Users and groups are added to /etc/passwd and /etc/group (or whichever default mechanism the corresponding platform supports). d368 1 a368 1
    4. Crontab entries are made (typically to /etc/crontab), to allow @ 1.31 log @Reword for clarity and reduction. @ text @d361 1 a361 1 run as roon however, and will alter the underlying system (admins running @ 1.30 log @Add sections on bootstrap entry points, and deinstallation integrity. @ text @d207 2 a208 3 Experiece showed that if you want to fulfill these requirements you are usually a lot faster with the from-scratch approach than with the take-over approach. @ 1.29 log @we can query names and ids @ text @d355 47 @ 1.28 log @work off "Userids and Groupids" and link to Handbook @ text @d459 1 a459 1 title="How can i query OpenPKG RPM to see which user/group ids are used?"> d463 1 @ 1.27 log @correct spelling of "privileges" @ text @d419 2 a420 2 Since OpenPKG 1.1 the bootstrapping package ("openpkg") requires four distinct Unix user/group id pairs: d438 1 a438 1 the "Example" values above are used achieved with --user=opkg d453 12 @ 1.26 log @perl-gcc @ text @d439 1 a439 1 --group=opkg. In case of a non-priviledged OpenPKG instance, d451 1 a451 1 bit more priviledges than the "nobody user/group" because (mostly @ 1.25 log @split off overriding-cc from overriding-cflags and enhance both @ text @d479 11 @ 1.24 log @overriding-cflags @ text @d457 2 a458 2 You should be able to achieve this by overriding the l_cc and l_cflags variables in your ~/.rpmmacros, i.e. d460 17 a476 2 %l_cc gcc %l_cflags -pipe -O3 -march=i686 -funroll-loops @ 1.23 log @Be more clear yet more general in wording, and refer users with specific platform questions to the handbook. @ text @d455 9 @ 1.22 log @Update supported platforms, correcting conflicting information. @ text @d116 9 a124 9 Solaris, Linux and FreeBSD because they are the most popular server platforms of the customers at Cable & Wireless Germany. As is clear from the detailed online documentation, OpenPKG users enjoy a level of partial support for NetBSD, OpenBSD, Tru64, and HP-UX as well. A quick read through the mailing list archive shows that efforts are undergoing or have been made to port OpenPKG to Darwin, AIX, IRIX, and Cygwin. These additional platforms are not fully supported however, because the resources needed to ensure correct package builds at OpenPKG central are simply not sufficient. @ 1.21 log @dedicated to Bill Campbell @ text @d111 1 a111 1 title="Why are currently only the operating systems Solaris, Linux and d113 12 a124 9 To begin with, OpenPKG can be used on any unsupported Unix flavors with just a few changes. However, we promise full support only to Solaris, Linux and FreeBSD because they are the most popular server platforms of the customers at Cable & Wireless Germany. Even with this intention, OpenPKG has been ported and tested on additional Unix platforms, including Tru64, HP-UX, OpenBSD, NetBSD, etc. These additional platforms are not fully supported however, because the resources needed to ensure correct package builds for them are exhausted. @ 1.20 log @fix markup @ text @d383 1 a383 1 title="Why does the OpenPKG bootstrap use \"compress\" data format?"> d405 7 a411 3 For building the "openpkg-*.src.sh" file, compress(1) is still required. But this build step is a developer only step where the extra installation of compress(1) is accepted. @ 1.19 log @add user/group id stuff @ text @d11 1 a11 2 d19 1 a19 1 @ 1.18 log @improve why-compress and mix in rse collision @ text @d318 1 a318 1 the 400 packages OpenPKG provides look rather tiny?"> d409 38 @ 1.17 log @clarify paragraph: gzip instead of bzip, plus more... @ text @d384 10 a393 10 title="Why does the OpenPKG bootstrap uses %22compress%22 data format?"> The "openpkg-*.src.sh" bootstrap package should run on as many platforms as possible. All platforms within the scope of OpenPKG support unpacking of data that comes in traditional compress(1) 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 tool installed by default but come with at least gunzip(1) which still can unpack the format of compress(1) and is automatically detected and used by the bootstrap. There is no other packed data format with equal availability. d395 14 a408 12 When a user creates an "openpkg-*.arch-os-id.sh" the resulting script was in "compress" format as well in OpenPKG v1.0 and v1.1 and CURRENT until 20030110 and. This required the availablity of compress(1) to the end-user. Unfortunately, as mentioned above, the latest incarnations of Linux omit that crucial tool and gzip(1) cannot create the compress(1) compatible data format. For this reason we droped compression in the packing of "openpkg-*.arch-os-id.sh" entirely beginning with CURRENT 20030113 and OpenPKG v1.2. For building the "openpkg-*.src.sh" file, compress(1) is still required. But this build step is a developer only step where the extra installation of compress(1) is accepted. @ 1.16 log @add why-compress to FAQ @ text @d385 9 a393 8 The "openpkg*src.sh" 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 tool installed by default but come with a "bunzip" which can unpack "compress" format and is detected and used by the bootstrap. There is no other packed data format with equal availability. d395 12 a406 8 When a user creates a "openpkg-*.arch-os-hierarchy.sh" the resulting script should be in "compress" format as well. This was the case in OpenPKG v1.0 and v1.1 and CURRENT until 20030110 and required the availablity of a "compress" tool to the user. As described above, the latest incarnations of LINUX omit that crucial tool and "bzip" cannot create "compress" data format. For this reason we decided to drop support for packing "openpkg-*.arch-os-hierarchy.sh" entirely beginning with CURRENT 20030113 and OpenPKG v1.2. @ 1.15 log @answer the porting question @ text @d34 1 a34 1
    5. Is there any background information available on the project name and logo?

      d43 1 d45 2 a46 3

    6. Why is RPM used and not <insert-your-favorite-tool> as the packaging tool?

      d66 1 d68 2 a69 3

    7. Can I use both the OpenPKG and my vendor RPM tool at the same time?

      d84 1 d86 3 a88 5

    8. Why is an OpenPKG specific RPM installed during bootstrap, even if most Linux distributions like RedHat, SuSE, etc. already come bundled with RPM 4?

      d96 1 d98 4 a101 6

    9. The problem with OpenPKG seems to be that it requires RPM on all target systems. This won't be popular with a lot of sys-admins because most want to stick with the vendor packaging systems whenever possible so that only a single install tool needs to be learned.

      d109 1 d111 3 a113 4

    10. Why are currently only the operating systems Solaris, Linux and FreeBSD fully supported?

      d123 1 d125 2 a126 3

    11. Can I use your source RPM packages with a plain RPM v4 environment?

      d131 1 d133 3 a135 4

    12. What do I have to change if I want to use a source RPM from another vendors with OpenPKG?

      d208 4 a211 3

    13. Why is there no Native Language Support (NLS) in OpenPKG packages?

      d237 1 d239 2 a240 3

    14. OpenPKG breaks with a few things from the good old Unix days. Why?

      d254 4 a257 11

    15. Is OpenPKG useful for me?

      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.

    16. What do I have to know for a successful deployment?

      d263 27 @ 1.9 log @one more point @ text @d113 76 @ 1.8 log @fix typo @ text @d77 14 @ 1.7 log @polishing @ text @d138 1 a138 1 it simple and stupid (KISS)" and "principle of least surprise." OpenPKG @ 1.6 log @added two Q&A @ text @d35 9 a43 7 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 fundemental needs of OpenPKG. d74 1 a74 1 RPM on Linux, and another on Solaris and FreeBSD is not acceptable. d77 2 a78 2

    17. Why are only the operating systems Solaris, Linux and FreeBSD fully supported? d80 9 a88 8 To begin with, OpenPKG can be used on any unsupported Unix flavors with just a few changes. However, we promise full support only to Solaris, Linux and FreeBSD because they are the most popular server platforms of the customers at Cable & Wireless Deutschland. Even with this intention, OpenPKG has been ported and tested on additional Unix platforms. These additional platforms are not fully supported however, because the resources needed to ensure correct package builds for them are exhausted. d95 2 a96 2 apply the rpmtool and shtool programs. It will therefore fail during any reference to a %{l_xxx} variable definition. d101 25 a125 24 There are many reasons why even packages which are shipped with NLS support are not packaged with NLS support. First, NLS is nice if the whole system, i.e., all packages, provides NLS support. But that is not the case for OpenPKG, because not all vendors support NLS in their programs. OpenPKG cannot provide NLS for them wholly, and a half solution is not acceptable.

      Second, we dislike the bloat 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.

      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 NLS support. With no ideal world, we think it is better to avoid NLS entirely. We extend our sympathy to those who prefer a non English language even on computers. d130 3 a132 2 Maybe you are thinking of the OpenPKG run-command (RC) system, the fact that in OpenPKG the tools use non-default filesystem paths, etc. pp? d141 2 d146 1 a146 1 When you install and maintain many UNIX machines or when you are doing d148 11 a158 7 consistent configurations.

    18. What do i have to know for a successful deployment?

      You need to understand some basics about RPM usage, the OpenPKG filesystem layout, the shell environment and the runcommand facility. The Tutorial and the Quick Reference are good starting points to gain that knowldege. @ 1.5 log @Nasty voodoo corrections. @ text @d136 12 @ 1.4 log @Intermediate commit. @ text @d76 1 a76 1 officially supported? d78 8 a85 8 Although technically the whole software packaging system can be used also on other Unix flavors with just a few changes, we officially support only Solaris, Linux and FreeBSD because these are the primary server platform of our customers at Cable & Wireless Deutschland. Nevertheless OpenPKG was already ported and tested on additional Unix platforms. It is just not officially supported, because we cannot afford to always make sure all of our packages build on such a lot of platforms. So we have to restrict the list of officially supported platforms. d88 1 a88 1

    19. Can I use your source RPM packages also with a plain RPM v4 environment? d90 4 a93 5 No, you can't, because our source RPM packages depend on RPM extensions which are not available with the plain RPM v4. For instance, if you are using a plain RPM v4, the rpmtool and shtool programs are not existing for you and all the %{l_xxx} variable definitions are missing. d102 2 a103 2 NLS in their programs, so OpenPKG cannot provide NLS for them. And a half-solution was not acceptable to us. d108 14 a121 14 are non-native English speakers, they like the idea that English was and should be kept as the only language spoken by Unix systems in order to not confuse people by strange translated messages.

      So, in a perfect world where all vendor packages ship with the same amount of NLS support (number of supported languages), where all translations are done correctly and consistently and where the filesystem is not bloated with hundred of extra files for each program just because hundred languages are spoken by the program, we would certainly allow OpenPKG to provide this NLS support. But until this state is reached in the Open Source world, we think it is better to avoid NLS at all. Sorry to those of you who usually prefer their native language over English even on computers. d126 2 a127 2 You are talking about the OpenPKG run-command (RC) system, the fact that in OpenPKG the tools use non-default filesystem paths, etc. pp. d129 7 a135 8 All this is confusing at the first look, of course. Nevertheless the decision for all this was lead by a lot of discussions and evaluations. We cannot answer this in detail here (read the OpenPKG handbook for details), but in general OpenPKG follows the philosophy: "keep it simple and stupid (KISS)" and "principle of least surprise" are fine in general and should be followed if possible, but if it means that something can be done more clean and orthogonal we break with this intentionally. @ 1.3 log @update FAQ @ text @d18 1 a18 1 idea to this symbolic was invented by Ralf S. Engelschall in April d32 2 a33 2 But to be honest, no tool actually provides a perfect solution for really all requirements we had in our mind. d38 4 a41 5 provided for all(!) of our essential wishes a good or at least reasonable solutions. The RedHat Package Manager (RPM) version 4 was of this type, although it certainly also has its drawbacks and pitfalls and is far away from being a perfect solution. But it is nevertheless perfect for OpenPKG because it provides the best balance when fulfilling our requirements. d46 14 a59 12 Yes, you can and have to use both at the same time. You just have to make sure you call the correct program, because both use the program name rpm. But do not panic, you cannot accidently use the wrong RPM tool: OpenPKG RPM specifications do not work with a vendor RPM tool, because the vendor RPM lacks the virtual "OpenPKG" pre-requisite definition (which is provided by the OpenPKG bootstrap package only). And vice versa, if you try to use your vendor RPM specifications with the OpenPKG RPM tool, it usually works, but remembers the installation in the wrong RPM database. So, the recommendation is to put your vendor rpm tool first into your $PATH and call the rpm of OpenPKG through an absolute path. d62 3 a64 2

    20. Why is an own RPM installed, even if most Linux distributions like RedHat, SuSE, etc. already ship with RPM 4? d66 7 a72 6 There are various reasons for this. One is that only this way our filesystem hierarchy can be maximum self-contained and independent. Another is that only this way we can adjust RPM freely to meet our wishes. And finally, this way we are consistent in our approach over all platforms, because using the vendor RPM on Linux but an own on Solaris and FreeBSD is not very consistent. @ 1.2 log @mention our NLS decision @ text @d4 1 a4 1 Frequently Asked Questions (FAQ) List d6 1 a6 1

      Frequently Asked Questions (FAQ) List

      d8 1 a8 2 This is a list of frequently asked questions and answers about our RPM-based software packaging system. d27 1 a27 1 companion pkg_xxxx(1) tools, the RedHat Package Manager (RPM), the d33 1 a33 1 really all requirements we had in our mind: d35 2 a36 16

      Writing a 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 d38 5 a42 3 provided for all above points good or at least reasonable solutions. The RedHat Package Manager (RPM) version 4 was of this type, although it certainly also has its drawbacks and pitfalls. d51 2 a52 2 with the vendor RPM tool, because the vendor RPM lacks the virtual "OpenPKG" prerequisite definition (which is provided by the OpenPKG d57 2 a58 12 into your $PATH. This way you do not have to think about these details very much.

    21. Why are only the operating systems Solaris, Linux and FreeBSD officially supported?

      Although technically the whole software packaging system can be used also on other Unix flavors with just a few changes, we officially support only Solaris, Linux and FreeBSD, because these are the primary server platform of our customers at Cable & Wireless Deutschland. Currently there is no plan to extend this list. d72 13 d89 3 a91 2 using a plain RPM v4, the "rpmtool" and "shtool" programs are not existing for you and all the "%{l_xxxx}" variables are not defined for you. d101 9 a109 7 a half-solution was not acceptable to us. Second, we dislike the bloat NLS support causes on the filesystem for each package, because in OpenPKG we try to strip down a package to its 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 spoken by Unix systems in order to not confuse people by strange translated messages. d120 15 @ 1.1 log @Initial revision @ text @d18 4 a21 1 and so symbolically stands for the term "software package". d24 1 a24 1

    22. Why is RPM used and not <INSERT-YOUR-FAVORITE> as the packaging tool? d28 4 a31 4 companion pkg_xxxx(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. d72 1 d101 26 @ 1.1.1.1 log @Import www.openpkg.org website @ text @@