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: 20-Feb-2004 16:18:36
Branch: HEAD Handle: 2004022015183600
Modified files:
openpkg-re news.txt upgrade.txt
Log:
consistently replace version syntax vN.M by N.M
Summary:
Revision Changes Path
1.35 +3 -3 openpkg-re/news.txt
1.30 +24 -24 openpkg-re/upgrade.txt
____________________________________________________________________________
patch -p0 <<'@@ .'
Index: openpkg-re/news.txt
============================================================================
$ cvs diff -u -r1.34 -r1.35 news.txt
--- openpkg-re/news.txt 20 Feb 2004 14:04:57 -0000 1.34
+++ openpkg-re/news.txt 20 Feb 2004 15:18:36 -0000 1.35
@@ -2,7 +2,7 @@
General Note
============
- o $Revision: 1.34 $. The most recent update of this file can be
+ o $Revision: 1.35 $. The most recent update of this file can be
downloaded from http://cvs.openpkg.org/openpkg-re/news.txt
o This file news.txt file talks about new features and major
@@ -128,7 +128,7 @@
o new tag feature
- In OpenPKG v2.0, binaries are named
+ In OpenPKG 2.0, binaries are named
"%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}-%{OS}-%{tag}.rpm" where the
tag is user configurable. It tag can be specified during bootstrap
using the new --tag=xxx option. It is then used as a default
@@ -486,7 +486,7 @@
The install-info that ships with Debian 3.1 (sarge) causes info.dir
files to appear in multiple packages. These packages conflict with
each other. See http://cvs.openpkg.org/chngview?cn=14711. The
- workaround to have OpenPKG v2.0 build binary RPMs on Debian v3.1
+ workaround to have OpenPKG 2.0 build binary RPMs on Debian 3.1
is to have the Debian install-info either not installed at all or
temporary replaced by /bin/true, i.e. using:
@@ .
patch -p0 <<'@@ .'
Index: openpkg-re/upgrade.txt
============================================================================
$ cvs diff -u -r1.29 -r1.30 upgrade.txt
--- openpkg-re/upgrade.txt 20 Feb 2004 14:04:57 -0000 1.29
+++ openpkg-re/upgrade.txt 20 Feb 2004 15:18:36 -0000 1.30
@@ -2,7 +2,7 @@
General Notes
=============
- o $Revision: 1.29 $. The most recent update of this file can be
+ o $Revision: 1.30 $. 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
@@ -62,7 +62,7 @@
o the following options were renamed
- OpenPKG v1.3 OpenPKG 2.0
+ OpenPKG 1.3 OpenPKG 2.0
--------------------- -----------------
with_berkeleydb with_bdb
with_db with_bdb
@@ -88,7 +88,7 @@
the build process of the application happy and allows them
to install and run. But the gdbm::with_ndbm file format on
disk is very likely different from that of the vendor's ndbm
- implementation. Upgrades from OpenPKG v1.3 will have used the
+ implementation. Upgrades from OpenPKG 1.3 will have used the
vendor ndbm previously. Now they use gdbm::with_ndbm. Any
damage can happen, from destroyed ndbm files to appliation
crashes to application malfunction (i.e. apache mod_auth_xxx
@@ -96,7 +96,7 @@
fresh installs and upgrades might run into trouble when they
mix vendor and OpenPKG software, i.e. use a vendor password
creation/maintenance tool which writes vendor ndbm files and use
- OpenPKG v2.0 application which reads gdbm::with_ndbm file format.
+ OpenPKG 2.0 application which reads gdbm::with_ndbm file format.
See http://cvs.openpkg.org/chngview?cn=14523
Upgraders have two options:
@@ -148,7 +148,7 @@
and hardcoded for all binaries being build with that bootstrap. The
prefix of the hierarchy was the input for location id creation.
- In OpenPKG v2.0, the location id is replaced by a user configurable
+ In OpenPKG 2.0, the location id is replaced by a user configurable
tag. See "new tag feature" in news.txt file.
For upgrades the default tag is <compat> to provide full backwards
@@ -184,11 +184,11 @@
$ /13/bin/rpm -qi openpkg
$ /20/bin/openpkg rpm -qi openpkg
- OpenPKG v2.0 provides a wrapper for "rpm" and "rpm2cpio" to be found
+ OpenPKG 2.0 provides a wrapper for "rpm" and "rpm2cpio" to be found
at the well known locations. They provide a compatible interface and
ensure existing automation scripts can be used unaltered. However,
every call to these legacy wrappers yields a big three line WARNING
- to STDERR. Please note that OpenPKG v2.1 will discontinue support
+ to STDERR. Please note that OpenPKG 2.1 will discontinue support
for these wrappers and any legacy application will fail unless it is
properly updated.
@@ -205,11 +205,11 @@
0 0 0 no OpenPKG installed
0 0 1 N/A
0 1 0 N/A
- 0 1 1 OpenPKG v2.1 (and later)
+ 0 1 1 OpenPKG 2.1 (and later)
1 0 0 OpenPKG v1.x w/o openpkg-tool
1 0 1 N/A
1 1 0 OpenPKG v1.x with openpkg-tool installed
- 1 1 1 OpenPKG v2.0 with /bin/rpm compatiblity wrapper
+ 1 1 1 OpenPKG 2.0 with /bin/rpm compatiblity wrapper
1 x 0 OpenPKG v1.x
x 1 1 OpenPKG v2.x
@@ -251,7 +251,7 @@
OpenPKG uses a package naming scheme that starts with
<name>-<version>-<release>. Details can be reviewed at
http://www.openpkg.org/cvs.txt, they did not change although OpenPKG
- never used snapshots and OpenPKG v2.0 makes no attempt to use a
+ never used snapshots and OpenPKG 2.0 makes no attempt to use a
SOLID branch. The version part is usually directly inherited from
the vendor version. There were always some packages where a vendor
version was not available. Examples are those that only reference
@@ -261,7 +261,7 @@
(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
- was a manual and error prone task. In fact OpenPKG v1.3 had such
+ 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
changes in OpenPKG v2.x:
@@ -330,7 +330,7 @@
- options:
examine installed packages for options that are in use and
manually check if options are still available with or renamed in
- OpenPKG v2.0
+ OpenPKG 2.0
$ %{l_prefix}/bin/rpm -qa --queryformat '%{name} provides: [%{PROVIDES} ]\n'
@@ -397,7 +397,7 @@
o important vendor updates:
- Package | v1.2 | v1.3
+ Package | 1.2 | 1.3
=============+=============+=============
mysql3 | n/a | 3.23.57
mysql | 3.23.54a | 4.0.14
@@ -442,11 +442,11 @@
default to "yes" and inhibit certain applications. Also keep in mind
that the execution of sections from "all" packages is additionaly
controlled by the "openpkg_runall" variable.
- OpenPKG v1.2 FOO_enable="yes"
- OpenPKG v1.3 FOO_enable="$openpkg_rc_def"
+ OpenPKG 1.2 FOO_enable="yes"
+ OpenPKG 1.3 FOO_enable="$openpkg_rc_def"
o This is a list of rc.conf variables that have been removed from
- OpenPKG v1.3 because their package was removed.
+ OpenPKG 1.3 because their package was removed.
-mysql4_enable="yes"
[EMAIL PROTECTED]@/etc/mysql4/my.pwd
@@ -462,11 +462,11 @@
[EMAIL PROTECTED]@/var/mysql4/update.log
o No new rc.conf variables were introduced by the new packages being
- added to OpenPKG v1.3.
+ added to OpenPKG 1.3.
o This this a complete list of rc.conf variable/value pairs that exist
in both releases of OpenPKG and which have been removed from OpenPKG
- v1.2 (-), added to OpenPKG v1.3 (+), changed (both - and +) or which
+ 1.2 (-), added to OpenPKG 1.3 (+), changed (both - and +) or which
remain untouched (=).
-amd_enable="yes"
@@ -930,7 +930,7 @@
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
+ o The OpenPKG 1.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
@@ -949,7 +949,7 @@
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:
+ exactly like previous releases of OpenPKG. Now for the news in 1.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
@@ -970,7 +970,7 @@
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
+ OpenPKG 1.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
@@ -1178,10 +1178,10 @@
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
+ those listed, switching to 1.1.0 is a real upgrade. If the numbers
+ match exactly switching to 1.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.
+ 1.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
@@ .
______________________________________________________________________
The OpenPKG Project www.openpkg.org
CVS Repository Commit List [EMAIL PROTECTED]
