OpenPKG CVS Repository
http://cvs.openpkg.org/
____________________________________________________________________________
Server: cvs.openpkg.org Name: Thomas Lotterer
Root: /e/openpkg/cvs Email: [EMAIL PROTECTED]
Module: openpkg-re Date: 15-May-2004 22:49:12
Branch: HEAD Handle: 2004051521491100
Modified files:
openpkg-re upgrade.txt
Log:
fix typos, grammar; minor fixes; cosmetics
Summary:
Revision Changes Path
1.43 +15 -14 openpkg-re/upgrade.txt
____________________________________________________________________________
patch -p0 <<'@@ .'
Index: openpkg-re/upgrade.txt
============================================================================
$ cvs diff -u -r1.42 -r1.43 upgrade.txt
--- openpkg-re/upgrade.txt 24 Mar 2004 16:31:38 -0000 1.42
+++ openpkg-re/upgrade.txt 15 May 2004 20:49:11 -0000 1.43
@@ -2,7 +2,7 @@
General Notes
=============
- o $Revision: 1.42 $. The most recent update of this file can be
+ o $Revision: 1.43 $. The most recent update of this file can be
downloaded from http://cvs.openpkg.org/openpkg-re/upgrade.txt
o This file upgrade.txt file talks about tweaks and quirks when
@@ -16,7 +16,7 @@
o Be aware that both major and minor OpenPKG upgrades might introduce
a new world order and are subject to change the OpenPKG experience
- in an incompatible way. Any possible damage could have been done to
+ in a incompatible way. Any possible damage could have been done to
any piece of the system including, but not limited to, packages
being split, consolidated or renamed, packages being replaced with
updated vendor versions. In rare cases packages might have be
@@ -51,7 +51,7 @@
Be sure no rpm process is hanging around and locking the database.
- $ /cw/bin/rpm --db-rebuild
+ $ %{l_prefix}/bin/openpkg rpm --db-rebuild
rpmdb: REBUILDING NEW FROM OLD RPM DATABASE (/cw/RPM/DB)
rpmdb: cleaning up RPM database DB region files
rpmdb: making sure RPM database contains all possible DB files
@@ -66,9 +66,10 @@
resources by setting ulimit(1) through the %{l_build_ulim} macro.
This can lead to situations where the build of a package breaks at
arbitrary points. If you want to modify the limits redefine the
- macro. For no limits set ~/.rpmmacros of the building user to %nil.
+ macro. For no limits set the macro to %nil in the building user's
+ ~/.rpmmacros.
- $ echo "%l_build_ulim %nil" >>$PREFIX/.rpmmacros
+ $ echo "%l_build_ulim %nil" >>%{l_prefix}/.rpmmacros
o openssh does not restart after upgrade
@@ -80,7 +81,7 @@
the installation or to kill the old daemon manually. In both cases
the new daemon has to be started manually.
- $ $PREFIX/etc/rc openssh start status
+ $ %{l_prefix}/etc/rc openssh start status
o the following options were renamed
@@ -98,7 +99,7 @@
with_openssl with_ssl
with_tls with_ssl
- o new ndbm behaviour
+ o new ndbm behavior
Vendors begin to remove ndbm from their distributions. Debian 3.1
(sarge) is known to be one of them. OpenPKG 2.0 uses its ndbm
@@ -157,7 +158,7 @@
The last step of upgrading the "openpkg" package is to use the 1.9
aka "Class:"-less 2.0 bootstrap to rebuild and install the real
openpkg-2.0.0-2.0.0.src.rpm. At this point the upgrade reaches a
- point undistinguishable from a fresh install.
+ point indistinguishable from a fresh install.
Note that a 1.x installation is not able to read 2.x binary RPMs.
When upgrading, it is a requirement using openpkg-1.3.1 to build the
@@ -173,7 +174,7 @@
The message appears when a bootstrap is not aware of the new
"Class:" header and is given a spec file which makes use of this
new feature. Upgrade the bootstrap. If the problem is building the
- boostrap during upgrade you probably tried to skip the intermediate
+ bootstrap during upgrade you probably tried to skip the intermediate
step.
o new tag feature to replace location id
@@ -297,7 +298,7 @@
In OpenPKG v1.x these packages had version=release both in CURRENT
(i.e. perl-conv-20040207-20040207.src.rpm) and RELEASE (i.e.
perl-comp-1.3.0-1.3.0.src.rpm). This is redundant information that
- made release engineering unnessessary hard. Adjusting the version
+ made release engineering unnecessarily hard. Adjusting the version
was a manual and error prone task. In fact OpenPKG 1.3 had such
a bug and the pam-20030715-1.3.0.src.rpm package had the version
unchanged by accident. This eventually triggered the following
@@ -323,14 +324,14 @@
- Packages which are bundles that have no real "master" version;
second solution: manually maintain version only (only is new)
- whenenver one of the vendor version changes.
+ whenever one of the vendor version changes.
openpkg-tool, kolab
In all cases of packages and branches the release is now maintained
independent of the version.
- Some of these changes make RPM think it performes a downgrade, so
+ Some of these changes make RPM think it performs a downgrade, so
--oldpackage might be required during an upgrade, see old "RPM
downgrade view" issue below. Example:
@@ -368,7 +369,7 @@
ensure the existing instance runs the OpenPKG 1.3.1 bootstrap
or a CURRENT bootstrap dated in the range 20030925 ... 20040130
inclusive. Later CURRENT bootstraps do not require special
- attention. Older boostraps need to be upgraded first. It is safest
+ attention. Older bootstraps need to be upgraded first. It is safest
if the installed packages match the bootstrap release/age.
- packages:
@@ -420,7 +421,7 @@
# %{l_prefix}/bin/rpm -Uvh openpkg-1.9.0-2.0.0.*-*.rpm
- Starting with a CURRENT bootstrap makes RPM think it performes a
+ Starting with a CURRENT bootstrap makes RPM think it performs a
downgrade, so --oldpackage is required during an upgrade, see old
"RPM downgrade view" issue below.
@@ .
______________________________________________________________________
The OpenPKG Project www.openpkg.org
CVS Repository Commit List [EMAIL PROTECTED]
