OpenPKG CVS Repository
http://cvs.openpkg.org/
____________________________________________________________________________
Server: cvs.openpkg.org Name: Michael Schloh
Root: /e/openpkg/cvs Email: [EMAIL PROTECTED]
Module: openpkg-re Date: 15-Oct-2004 17:08:49
Branch: HEAD Handle: 2004101516084900
Modified files:
openpkg-re releasenotes.txt
Log:
edit general upgrade notes correcting english punctuation, grammar, style,
and usage, and strip double sentence spaces to conform to internal
documentation standards
Summary:
Revision Changes Path
1.5 +42 -35 openpkg-re/releasenotes.txt
____________________________________________________________________________
patch -p0 <<'@@ .'
Index: openpkg-re/releasenotes.txt
============================================================================
$ cvs diff -u -r1.4 -r1.5 releasenotes.txt
--- openpkg-re/releasenotes.txt 17 Aug 2004 06:24:01 -0000 1.4
+++ openpkg-re/releasenotes.txt 15 Oct 2004 15:08:49 -0000 1.5
@@ -2,46 +2,53 @@
OpenPKG Release Notes
=====================
- o $Revision: 1.4 $. The most recent update of this file can be
+ o $Revision: 1.5 $. The most recent update of this file can be
downloaded from http://cvs.openpkg.org/openpkg-re/releasenotes.txt
The history of this document, specific versions and
differences between versions can be retrieved from
http://cvs.openpkg.org/rlog?f=openpkg-re/releasenotes.txt
- o This releasenotes.txt file talks about new features and major
- improvements introduced in a OpenPKG release. It also talks about
- tweaks and quirks when upgrading, common pitfalls and ways to bypass
- them.
+ o This file describes new features and major improvements introduced
+ in the respective OpenPKG release. It can be of help when upgrading,
+ especially in avoiding the most common upgrade problems.
- o It consolidates and obsoletes the previous news.txt and upgrade.txt
+ o This file accompanies news.txt which serves as a one page
+ generalization of OpenPKG's life history.
+
+ o This file obsoletes upgrade.txt
General Notes about Upgrading
=============================
- o You cannot skip a version. That means, upgrading from 0.9 to 1.1
- requires an upgrade to 1.0 as an intermediate step. Note that 2.0
- is the immediate successor of 1.3.
-
- 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 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
- removed and no upgrade path exists at all. Package options and rc
- variables might have been changed. OpenPKG itself might provide new
- and incompatible modifications, obsolete parts might have been
- removed. Do not expect a OpenPKG instance can be upgraded by just
- building and upgrading every package and everything continues to run
- without manual adjustments.
-
- o In contrast, OpenPKG security updates are designed to be drop-in
- replacements and usually require little or no brain work. They
- appear after a release was done. That's why they are not discussed
- here. Please keep in mind that any new release raises the bar of
- security compatibility as we only support the latest release and
- it's immediate predecessor. So don't fall behind by running outdated
- releases for prolonged times.
+ o Skipping a version is highly unadvised. That means that upgrading from
+ 0.9 to 1.1 requires an upgrade to 1.0 as an intermediate step. Note that
+ 2.0 is the immediate successor of 1.3.
+
+ o It is wisest to limit as much infrastructure within a single OpenPKG
+ instance to the corresponding OpenPKG version. That means that while
+ it is technically possible, mixing packages from across several versions
+ is not advisable.
+
+ o Be aware that as new features and improvements are added, both major
+ and minor OpenPKG upgrades might introduce incompatabilities with older
+ OpenPKG components. Packages are always upgraded to their most stable
+ and up to date vendor versions. However, packages may be split,
+ consolidated, or renamed as well. In rare cases packages are removed,
+ leaving no upgrade path at all. OpenPKG is only released after a quality
+ assurance process confirms its integrity, but in most cases some
+ testing, adjustment, or other postupgrade administration is needed.
+ Please plan accordingly when upgrading to a new version.
+
+ o In contrast to package version upgrades, OpenPKG security updates are
+ designed to be drop-in replacements and usually require little or no
+ brain work. These packages appear in the UPD (update) subdirectory of
+ a release after the delivery date.
+
+ Importantly, the extent of security engineering advances with each
+ new OpenPKG release. This means that security advisories and their
+ associated UPD packages are only issued for the latest OpenPKG release
+ and its immediate predecessor. Continuing to run outdated release
+ packages not within the aforementioned security range introduces risks.
New in OpenPKG 2.1
==================
@@ -1264,7 +1271,7 @@
o the rc variable "openpkg_runall" was renamed to "openpkg_rc_all".
Presence of the obsolete variable is detected, a warning is printed
and the value of the obsolete variable overrides the newly
- introduced variable, if both exist. The meaning remains the same.
+ introduced variable, if both exist. The meaning remains the same.
It controls whether a "rc all ..." instruction will run anything or
not. Note the bootstrap uses "rc all start" and "rc all stop" on
system boot and shutdown so this effectively enables or disables the
@@ -1278,9 +1285,9 @@
o the rc variable "FOO_enable" for any package can be overridden in
the "rc.conf" file to enable or disable rc sections for a specific
- package. This works identical to previous versions. However, with
+ package. This works identical to previous versions. However, with
the new "openpkg_rc_def" the default for all "FOO_enable" variables
- omitted from "rc.conf" can be controlled now. This means it is now
+ omitted from "rc.conf" can be controlled now. This means it is now
possible to default to "no" and only launch certain applications or
default to "yes" and inhibit certain applications. Also keep in mind
that the execution of sections from "all" packages is additionaly
@@ -1767,7 +1774,7 @@
information about the status of a package, namely "enable",
"useable" and "active". The output format is in bourne shell
variable assignment syntax so it can be eval'ed from scripts. It's
- also human readable. A package is enabled if it's effective value
+ also human readable. A package is enabled if it's effective value
of "FOO_enable" is set to "yes". Some (few) packages have config
checkers and usable means they're ready to launch. Many packages
return "unknown" here. A package is active when it's daemon is up
@@ -2164,7 +2171,7 @@
The nature of the OpenPKG release engineering version number scheme
unconditionally makes RPM think that 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
+ 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.
@@ .
______________________________________________________________________
The OpenPKG Project www.openpkg.org
CVS Repository Commit List [EMAIL PROTECTED]
