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: 31-Jul-2003 16:46:56
Branch: HEAD Handle: 2003073115465600
Modified files:
openpkg-re upgrade.txt
Log:
The OpenPKG v1.3 way of upgrading a package
Summary:
Revision Changes Path
1.11 +93 -0 openpkg-re/upgrade.txt
____________________________________________________________________________
patch -p0 <<'@@ .'
Index: openpkg-re/upgrade.txt
============================================================================
$ cvs diff -u -r1.10 -r1.11 upgrade.txt
--- openpkg-re/upgrade.txt 31 Jul 2003 14:42:38 -0000 1.10
+++ openpkg-re/upgrade.txt 31 Jul 2003 14:46:56 -0000 1.11
@@ -569,6 +569,99 @@
return "unknown" here. A package is active when it's daemon is up
and running.
+ o The OpenPKG v1.3 way of upgrading a package
+
+ 1st) build the package (--rebuild --define 'feature yes')
+ 2nd) rescue your configuration, unless it is build from an external source
+ 3rd) upgrade the package (-Uvh)
+ 4th) handle and remove all .rpm(save|old|orig) files
+ 5th) start the service (%{l_prefix}/etc/rc service start)
+ 6th) [ erase a package (-e) ]
+
+ The first step is not different from previous releases of OpenPKG.
+
+ The second step might be anything from nothing and restart from
+ scratch, copying, archiving or ignoring it completely because
+ you have a configuration management system which builds the
+ configuration from a source external to OpenPKG.
+
+ The third step upgrades the package and copies the files to the
+ system. This might include modification of configuration files
+ which results in .rpm(save|old|orig) copies/suggestions. This works
+ exactly like previous releases of OpenPKG. Now for the news in v1.3:
+ all CORE and BASE packages have been tuned to restart the service
+ (= daemon that comes within a package) after upgrade (find comment
+ "after upgrade, restart service" in %post section of the spec). A
+ restart will keep stopped services stopped and running services will
+ experience a stop/start combination. We found two categories of
+ services. Regarding the restart issue, a simple service can continue
+ to run during the upgrade and only requires a "rc service restart"
+ after the upgrade (i.e. openssh). This works for any service that
+ only reads it's configuration during startup. The majority of
+ services falls into this category. Some complex ones read their
+ configuration while they are up and running (i.e. postfix) based
+ on new connections, timing, external signal, timestamp monitoring
+ or whatever. Or they require more complex upgrade activity like
+ user data conversion (i.e. postgresql). For the complex ones (find
+ comment "before upgrade, save status and stop service" of the %pre
+ section in the spec) the running state is saved before the upgrade,
+ the service is stopped using "rc service stop" and after the upgrade
+ the state is recovered, if possible, executing a "rc service start".
+
+ The fourth step is already tied closely to the the third one. In
+ OpenPKG v1.3, "rc" checks if it finds any .rpm(save|old|orig) files
+ in or below the package's %{l_prefix}/etc/%{name}/ directory. For
+ %start and %restart actions this situation is considered an error,
+ a message is printed to stderr (and sent to you via mail if it's
+ executed by cron, i.e. log file rotation in %daily scriptlet) and
+ starting or restarting is effectively inhibited. For all other
+ sections, including %status and %env, this situation is considered a
+ warning, a message is printed to stderr (...cron...) but execution
+ will continue. This behaviour is already true for the final %post
+ scriptlet in the third step discussed above. Simple services just
+ won't restart and the old one will continue to run (rc %restart
+ is suppressed) until stopped somehow. Complex services have been
+ shut down in the %pre scriptlet (rc %stop) and might not come up
+ again after the upgrade (rc %start is suppressed). This altogether
+ leads to the point that after an upgrade, the new service might
+ not be startable. You have to move the .rpm(save|old|orig) out of
+ "rc" sight by renaming, moving or removing them somehow. This could
+ be done manually, it could also be done automatically by a 3rd
+ party configuration management. As a sidenote please understand the
+ default configuration of all CORE and BASE packages (except ntp and
+ amd) were altered to force the daemon to listen on 127.0.0.1. This
+ reduces interference with other (system, different OpenPKG instance)
+ similar services. It also ensures that the service is not exposed to
+ the outer world without your explicit configuration, this enhances
+ security (and increases travel expenses if you forget to tweak your
+ sshd_config!). Last but not least, it means that services which do
+ awkward (i.e. apache showing default index page) or deadly (i.e.
+ postfix rejecting incoming mails) things in the default config won't
+ do it without making you fully responsible :-)
+
+ The fifth step is only necessary if the running state should
+ forcibly change after an upgrade or the automatic run state recovery
+ that executed in the %post scriptlet before the configuration
+ management cleaned out things failed. After the blocking files
+ have been removed, further "rc start" or "rc restart" actions will
+ succeed. Note that simple services will have the old service up
+ and running and require a %restart (= %stop %start) while complex
+ services were already stopped and require a %start. Note that
+ %restart will not do anything if the service is not already running.
+ Also note that %start will not do anything if the service is already
+ running. If you're in doubt, execute "rc service restart start"
+ after configuration management took place.
+
+ Just for completeness, the sixth step would be a package erase.
+ All CORE and BASE packages were tuned to shut down the service
+ (find comment "before erase, stop service" in %preun section of
+ the spec), erase log (including statistics and history) and run
+ (pidfiles, UNIX domain socket files) files without notice. If you
+ want to keep them, refrain from erasing or save that data first.
+ User data like databases will not be removed, of course (trusting
+ this statement blindly and omitting backups might result in an
+ interesting experience of life :-)
+
o FIXME
- mention sharutils requirement (SuSE)
- mention solaris requirements (feedback from Ingo)
@@ .
______________________________________________________________________
The OpenPKG Project www.openpkg.org
CVS Repository Commit List [EMAIL PROTECTED]
