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
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.
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:
%attr
in %files
.
Writing conforming packages from scratch usually takes much less effort and time than the alternative approach of adjusting a not conforming one.
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.
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.
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.
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:
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:
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
%l_cflags -pipe -O3 -march=i686 -funroll-loops
%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 ...
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:
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.
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.
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.
d24 1 d29 1 a29 1
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.
d43 1 d45 2 a46 3
d66 1 d68 2 a69 3
d84 1 d86 3 a88 5
d96 1 d98 4 a101 6
d109 1 d111 3 a113 4
d123 1 d125 2 a126 3
d131 1 d133 3 a135 4
d208 4 a211 3
d237 1 d239 2 a240 3
d254 4 a257 11
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.
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
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.
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
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
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.
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