OpenPKG CVS Repository
http://cvs.openpkg.org/
____________________________________________________________________________
Server: cvs.openpkg.org Name: Ralf S. Engelschall
Root: /e/openpkg/cvs Email: [EMAIL PROTECTED]
Module: openpkg-web Date: 12-Jul-2003 13:50:05
Branch: HEAD Handle: 2003071212500400
Modified files:
openpkg-web faq.wml
Log:
cleanup markup, fix typos, add package type FAQ entry
Summary:
Revision Changes Path
1.37 +110 -26 openpkg-web/faq.wml
____________________________________________________________________________
patch -p0 <<'@@ .'
Index: openpkg-web/faq.wml
============================================================================
$ cvs diff -u -r1.36 -r1.37 faq.wml
--- openpkg-web/faq.wml 22 Apr 2003 13:55:41 -0000 1.36
+++ openpkg-web/faq.wml 12 Jul 2003 11:50:04 -0000 1.37
@@ -59,7 +59,7 @@
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.
+ 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.
</faq>
@@ -67,10 +67,10 @@
<faq id="vendor-rpm"
title="Can I use both the OpenPKG and my vendor RPM at the same time?">
Yes, you can. It might even be necessary, as our RPM tool provides a
- different set of functionality as the traditional one. Unfortunatly, both
+ 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 accidently apply the
+ 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
@@ -155,7 +155,7 @@
<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 youself by taking over ideas and the
+ 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
@@ -204,8 +204,8 @@
<tt>%install</tt>. But it especially requires the previous point.
</ul>
<p>
- Writing conformant packages from scratch usually takes much less effort
- and time than the alternative approach of adjusting a nonconformant one.
+ Writing conforming packages from scratch usually takes much less effort
+ and time than the alternative approach of adjusting a not conforming one.
</faq>
<faq id="no-nls"
@@ -250,7 +250,7 @@
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 breaked as result of making
+ Additionally, sometimes standards had to be broken as result of making
OpenPKG a stand-alone and self-contained sub-system.
</faq>
@@ -260,7 +260,7 @@
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 knowldege.
+ starting points to gain that knowledge.
</faq>
<faq id="no-shlib"
@@ -268,7 +268,7 @@
platforms, the philosophy is to dynamically link everything.">
A clarification: in OpenPKG executables are dynamically linked against
operating system (external) libraries, of course. What you are talking
- about is the linking agains the OpenPKG provided (internal) libraries.
+ 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>
@@ -296,7 +296,7 @@
versions (see <a here="/cvsweb/cvsweb.cgi/openpkg-re/vcheck/">here</a> for
details) 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 tries to
+ 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.
@@ -309,7 +309,7 @@
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 brokeness is discovered later only. But it is at last
+ 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.
</faq>
@@ -352,7 +352,7 @@
</faq>
<faq id="entry-points"
- title="What will the bootstrap prodedure (as root user) do to my system?">
+ title="What will the bootstrap procedure (as root user) do to my system?">
<p>
The bootstrap procedure has only one purpose, and that is to install a new
OpenPKG instance. Remember that the procedure accomplishes this in two
@@ -389,7 +389,7 @@
<p>
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 dependant package exists, OpenPKG will require that it first be
+ 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
@@ -446,7 +446,7 @@
"<tt>openpkg-*.<i>arch</i>-<i>os</i>-<i>hierarchy</i>.sh</tt>"
binary bootstrap the resulting script was in "compress" format in
OpenPKG v1.0, v1.1 and CURRENT until 20030110. This required the
- availablity of compress(1) to the user. As described above, 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
@@ -467,6 +467,7 @@
Starting with OpenPKG 1.1 the bootstrapping package ("openpkg") uses
four distinct Unix user/group id pairs, previous versions used only two.
<p>
+<box bdwidth=1 bdcolor="#a5a095" bdspace=10 bgcolor="#e5e0d5">
<pre>
Name Option RPM-Macro Default Example Files Proc.
---------------- ------ --------- ------------- ------- ----- -----
@@ -479,6 +480,7 @@
nobody user --nusr %{l_nusr} <user>-n opkg-n none most
nobody group --ngrp %{l_ngrp} <group>-n opkg-n none most
</pre>
+</box>
<p>
The default values are derived from the options
<tt>--user=<user></tt> and <tt>--group=<group></tt>
@@ -493,7 +495,7 @@
The reason mainly is that the "super user/group" executes files
intentionally owned by the "managing user/group".
<p>
- Similarily the "restricted user/group" and "nobody 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
@@ -505,21 +507,21 @@
<faq id="uid-query"
title="How can i query OpenPKG RPM to see which user/group names/ids are
used?">
+ <p>
<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>
+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>
</faq>
<faq id="overriding-cflags"
title="How can i override the CFLAGS default for all packages?">
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>
+%l_cflags -pipe -O3 -march=i686 -funroll-loops</pre>
</faq>
<faq id="overriding-cc"
@@ -528,14 +530,15 @@
<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>
+%l_cc /usr/local/bin/gcc</pre>
+ <p>
Alternatively, you can override <tt>%l_cc</tt> for a single rebuild
by defining "with_cc".
+ <p>
<pre>
- .../rpm --define "with_cc /usr/local/bin/gcc" --rebuild ...
- </pre>
+.../rpm --define "with_cc /usr/local/bin/gcc" --rebuild ...</pre>
</faq>
<faq id="perl-gcc"
@@ -548,5 +551,86 @@
package has "gcc" listed as both a <tt>BuildPreReq</tt> and a
<tt>PreReq</tt>.
</faq>
+
+<faq id="package-type"
+ title="What are physical/virtual/replacement/alternative packages?">
+ In OpenPKG, there are three distinct types of packages when
+ it comes to provided package targets for package dependencies:
+ <p>
+<box bdwidth=1 bdcolor="#a5a095" bdspace=10 bgcolor="#e5e0d5">
+<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
+</box>
+ <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.
+ <p>
+ <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>only 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.
+ </ul>
+</faq>
+
</ol>
@@ .
______________________________________________________________________
The OpenPKG Project www.openpkg.org
CVS Repository Commit List [EMAIL PROTECTED]
