OpenPKG CVS Repository
http://www.openpkg.org/cvsweb/cvsweb.cgi
____________________________________________________________________________
Server: cvs.openpkg.org Name: Ralf S. Engelschall
Root: /e/openpkg/cvs Email: [EMAIL PROTECTED]
Module: openpkg-adm Date: 29-Aug-2002 11:16:34
Branch: HEAD Handle: 2002082910163400
Modified files:
openpkg-adm upgrade.txt
Log:
more details
Summary:
Revision Changes Path
1.5 +137 -101 openpkg-adm/upgrade.txt
____________________________________________________________________________
Index: openpkg-adm/upgrade.txt
============================================================
$ cvs diff -u -r1.4 -r1.5 upgrade.txt
--- openpkg-adm/upgrade.txt 29 Aug 2002 08:25:37 -0000 1.4
+++ openpkg-adm/upgrade.txt 29 Aug 2002 09:16:34 -0000 1.5
@@ -4,111 +4,147 @@
You cannot skip a version. That means, upgrading from 0.9 to 1.1
requires an upgrade to 1.0 as an intermediate step.
+
+ Upgrade from OpenPKG 1.0 to OpenPKG 1.1
+ =======================================
+
+ o Additional accounts:
+
+ Additional user accounts will be added to the system. The new UIDs
+ are not used by the bootstrap itself and can be changed by manually
+ configuring the system files immediately after the upgrade. Do not
+ modify them after any dependent packages were installed (i.e. postfix
+ and sendmail) as these packages might compile UIDs into the binary.
- OpenPKG Bootstrap "downgrade" from CURRENT to openpkg-1.1
- =========================================================
+ o rsync rc.conf Variables:
+
+ Previously the rsync package used (inconsistently) rc.conf variables
+ with prefix "rsyncd_". This was now corrected to be "rsync_". You
+ have to manually change your existing rc.conf entries.
+
+ o bind v8/v9:
+
+ In OpenPKG 1.1 the "bind" package is based on BIND 9 so the
+ package is named "bind-9.x.x-1.1.x". The old OpenPKG 1.0 package
+ "bind-8.x.x-1.0.0" became "bind8-8.x.x-1.1.0". This means you have
+ to deinstall "bind" and install from scratch "bind8" if you want to
+ stick with BIND 8. Make sure you backup <prefix>/etc/bind/ first.
+
+ o PAM:
+
+ In OpenPKG 1.0 some daemon packages by default had PAM support
+ enabled. Unfortunately PAM makes trouble in a cross-platform
+ approach, hence OpenPKG 1.1 has PAM support disabled in all packages
+ by default. Instead PAM support can be consistently enabled there
+ through a --define "with_pam yes" during build-time. This now
+ requires the "pam" glue package to be installed first. This "pam"
+ package now takes over the task of re-configuring the /etc/pam.d/ or
+ /etc/pam.conf in a consistent way.
+
+ o Bootstrapping and C Compiler:
+
+ For machines which do not have any C compiler at all (Solaris!), you
+ usually have to install a gcc via binary somewhere. If it is outside
+ the OpenPKG hierarchy, the sane build environment prevents OpenPKG
+ from finding and using it. To tell OpenPKG about this "cc" you have to
+ add an ~/.rpmmacros with "%with_cc /path/to/this/bootstrap/cc".
- If binutils and gcc-3.2 were installed previously, binutils, gcc and
- openpkg must be upgraded in exacly that order.
+ Upgrade from OpenPKG-CURRENT to OpenPKG 1.1
+ ===========================================
+
+ o RPM downgrade view:
+
+ Please understand the difference between a real up-/downgrade compared
+ to what RPM thinks is a up-/downgrade.
- Due to a problem with binutils before 200208261229 FreeBSD users will
- receive static ELF binaries with wrong brand. The loader will reject
- them with error 'ELF binary type "0" not known'. Unfortunately, the
- /cw/lib/openpkg/rpm executable called by the /cw/bin/rpm wrapper is
- such a binary. If you receive this error the last chance to recover is
- to brand the binary manually, i.e. using
-
- $ brandelf -t "FreeBSD" /cw/lib/openpkg/rpm
-
- The following table shows the three critical packages and tells which
- are identical besides the number. If CURRENT packages are older than
- those listed, switching to v1.1.0 is a real upgrade. If the numbers
- match exactly switching to v1.1.0 will not change anything but the
- number. If CURRENT packages are newer than those listed, switching to
- v1.1.0 is a real downgrade.
-
- openpkg-20020826-20020826 = openpkg-1.1.0-1.1.0
- binutils-2.13-20020826 = binutils-2.13-1.1.0
- gcc-3.2-20020815 = gcc-3.2-1.1.0
-
- Please understand the difference between a real up-/downgrade compared
- to what RPM thinks is a up-/downgrade.
-
- The nature of the OpenPKG release engineering version number scheme
- unconditionally makes RPM thinking the step from CURRENT to any
- release is a downgrade. Use --oldpackage along with -Uvh to cheat and
- force RPM to accept that "downgrade". Some packages might require an
- additional --nodeps to unchain version dependencies for the same
- reason. An alternative to ignoring depencencies is to specify all
- dependent packages on a single command line.
-
- OpenPKG Bootstrap Upgrade from openpkg-1.0 to openpkg-1.1
- =========================================================
-
- Additional user accounts will be added to the system. The new UIDs
- are not used by the bootstrap itself and can be changed by manually
- configuring the system files immediately after the upgrade. Do not
- modify them after any dependent packages were installed (i.e. postfix
- and sendmail) as these packages might compile UIDs into the binary.
-
- For machines which do not have any C compiler at all (Solaris!), you
- usually have to install a gcc via binary somewhere. If it is outside
- the OpenPKG hierarchy, the sane build environment prevents OpenPKG
- from finding and using it. To tell OpenPKG about this "cc" you have to
- add an ~/.rpmmacros with "%with_cc /path/to/this/bootstrap/cc".
-
- OpenPKG Bootstrap Upgrade from openpkg-0.9-N to openpkg-1.0
- ===========================================================
-
- No big deal.
-
- OpenPKG Bootstrap Upgrade from rpm-4.0-N to openpkg-0.9-N
- =========================================================
-
- Until July 2001 the OpenPKG (http://www.openpkg.org/) bootstrap
- package was named "rpm-4.0-N". Because over the time it mutated into
- something which is actually a lot more than just RPM, it was renamed
- to "openpkg-0.9-N" recently. For safe upgrading in the future, it is
- _VERY_ important that all already existing OpenPKG installations are
- _NOW_ upgraded to the new bootstrap package.
-
- For the experts: it has to be done before we rename/add/delete files
- in forthcoming openpkg-0.9-X versions, because else a complete
- re-install would be required later or the database would be no longer
- in sync with the installed files if you upgrade too late.
-
- To determine whether an OpenPKG hierarchy has to be upgraded, run the
- following command:
-
- # 0. determine current state
- $ rpm -qa | egrep '(rpm|openpkg)'
-
- If the output is "rpm-4.0-X" upgrading is required. If the output is
- "openpkg-0.9-X" upgrading was already done (perhaps by someone else)
- and so you do _NOT_ have to upgrade immediately.
-
- If upgrading is required, enter as soon as possible the following
- commands as "root" exactly as they are written down here and in
- exactly this order for every OpenPKG filesystem hierarchy (replace /cw
- with the path to your particular OpenPKG hierarchy):
-
- # 1. enter the OpenPKG filesystem hierarchy (for relative paths below)
- $ cd /cw
-
- # 2. rebuild the OpenPKG bootstrap package for this hierarchy
- $ bin/rpm --rebuild http://www.openpkg.org/pkg/openpkg-0.9-8.src.rpm
-
- # 3. remove the old bootstrap name from RPM database
- $ bin/rpm -e --justdb --nodeps rpm
-
- # 4. install the new bootstrap [expect 2 warnings]
- $ bin/rpm -i --noscripts --nodeps --force RPM/PKG/openpkg-0.9-8.*.rpm
+ The nature of the OpenPKG release engineering version number scheme
+ unconditionally makes RPM thinking the step from CURRENT to any
+ release is a downgrade. Use --oldpackage along with -Uvh to cheat and
+ force RPM to accept that "downgrade". Some packages might require an
+ additional --nodeps to unchain version dependencies for the same
+ reason. An alternative to ignoring depencencies is to specify all
+ dependent packages on a single command line.
+
+ o binutils/gcc/openpkg:
+
+ If binutils and gcc-3.2 were installed previously, binutils, gcc and
+ openpkg must be upgraded in exacly that order.
+
+ Due to a problem with binutils before 200208261229 FreeBSD users will
+ receive static ELF binaries with wrong brand. The loader will reject
+ them with error 'ELF binary type "0" not known'. Unfortunately, the
+ /cw/lib/openpkg/rpm executable called by the /cw/bin/rpm wrapper is
+ such a binary. If you receive this error the last chance to recover is
+ to brand the binary manually, i.e. using
- # 5. rebuild the RPM database
- $ bin/rpm --rebuilddb
+ $ brandelf -t "FreeBSD" /cw/lib/openpkg/rpm
+
+ The following table shows the three critical packages and tells which
+ are identical besides the number. If CURRENT packages are older than
+ those listed, switching to v1.1.0 is a real upgrade. If the numbers
+ match exactly switching to v1.1.0 will not change anything but the
+ number. If CURRENT packages are newer than those listed, switching to
+ v1.1.0 is a real downgrade.
+
+ openpkg-20020826-20020826 = openpkg-1.1.0-1.1.0
+ binutils-2.13-20020826 = binutils-2.13-1.1.0
+ gcc-3.2-20020815 = gcc-3.2-1.1.0
+
+
+ Upgrade from OpenPKG 0.9 to OpenPKG 1.0
+ =======================================
+
+ No known issues.
- # 6. cleanup after upgrade
- $ rm -f etc/rpm/*.rpmorig
+ Upgrade from rpm-4.0-N to OpenPKG 0.9
+ =====================================
- For more details or help in case of problems, feel free to contact me.
+ o Upgrading Bootstrap Package:
+
+ Until July 2001 the OpenPKG (http://www.openpkg.org/) bootstrap
+ package was named "rpm-4.0-N". Because over the time it mutated into
+ something which is actually a lot more than just RPM, it was renamed
+ to "openpkg-0.9-N" recently. For safe upgrading in the future, it is
+ _VERY_ important that all already existing OpenPKG installations are
+ _NOW_ upgraded to the new bootstrap package.
+
+ For the experts: it has to be done before we rename/add/delete files
+ in forthcoming openpkg-0.9-X versions, because else a complete
+ re-install would be required later or the database would be no longer
+ in sync with the installed files if you upgrade too late.
+ To determine whether an OpenPKG hierarchy has to be upgraded, run the
+ following command:
+
+ # 0. determine current state
+ $ rpm -qa | egrep '(rpm|openpkg)'
+
+ If the output is "rpm-4.0-X" upgrading is required. If the output is
+ "openpkg-0.9-X" upgrading was already done (perhaps by someone else)
+ and so you do _NOT_ have to upgrade immediately.
+
+ If upgrading is required, enter as soon as possible the following
+ commands as "root" exactly as they are written down here and in
+ exactly this order for every OpenPKG filesystem hierarchy (replace /cw
+ with the path to your particular OpenPKG hierarchy):
+
+ # 1. enter the OpenPKG filesystem hierarchy (for relative paths below)
+ $ cd /cw
+
+ # 2. rebuild the OpenPKG bootstrap package for this hierarchy
+ $ bin/rpm --rebuild http://www.openpkg.org/pkg/openpkg-0.9-8.src.rpm
+
+ # 3. remove the old bootstrap name from RPM database
+ $ bin/rpm -e --justdb --nodeps rpm
+
+ # 4. install the new bootstrap [expect 2 warnings]
+ $ bin/rpm -i --noscripts --nodeps --force RPM/PKG/openpkg-0.9-8.*.rpm
+
+ # 5. rebuild the RPM database
+ $ bin/rpm --rebuilddb
+
+ # 6. cleanup after upgrade
+ $ rm -f etc/rpm/*.rpmorig
+
+ For more details or help in case of problems, feel free to contact me.
+
______________________________________________________________________
The OpenPKG Project www.openpkg.org
CVS Repository Commit List [EMAIL PROTECTED]
