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: 30-Jan-2004 21:25:49
Branch: HEAD Handle: 2004013020254900
Modified files:
openpkg-re upgrade.txt
Log:
talk about tags, headers, sections and intermediate upgrade step
Summary:
Revision Changes Path
1.21 +90 -1 openpkg-re/upgrade.txt
____________________________________________________________________________
patch -p0 <<'@@ .'
Index: openpkg-re/upgrade.txt
============================================================================
$ cvs diff -u -r1.20 -r1.21 upgrade.txt
--- openpkg-re/upgrade.txt 30 Jan 2004 09:26:03 -0000 1.20
+++ openpkg-re/upgrade.txt 30 Jan 2004 20:25:49 -0000 1.21
@@ -2,7 +2,7 @@
General Notes
=============
- o $Revision: 1.20 $. The most recent update of this file can be
+ o $Revision: 1.21 $. 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
@@ -105,6 +105,95 @@
compatible to vendor ndbm. Existing ndbm files must be rebuild or
applications must explicitly use vendor ndbm (if available) by being
build with no gdbm_ndbm. See http://cvs.openpkg.org/chngview?cn=14523
+
+ o new tag feature to replace location id
+
+ In OpenPKG v1.x, binaries were named
+ "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}-%{OS}-%{l_location}.rpm"
+ where location was computed during installation of the bootstrap
+ 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.x, the location id was replaced by a user
+ configurable tag. The tag can be specified during bootstrap
+ using the new --tag=xxx option. It is then used as a default
+ for every binary package being build. It can be overridden for
+ every individual binary package by specifying the --tag=xxx
+ option on a --rebuild or -bb or -ba command line. See
+ http://cvs.openpkg.org/chngview?cn=14312
+
+ The tag is even more powerful as it is not a constant string but a
+ macro that is expanded during the build process. This allows for
+ creation of dynamic tags.
+
+ More precisely from a users perspective the tag is actually a tag
+ format (tagfmt). To enhance convenience for the user some predefined
+ combinations or macros are provided which can be specified using
+ their name in angle brackets. The default tagfmt is <compat> (FIXME
+ reality currently is <loc>) which provides exactly the same output
+ as OpenPKG v1.3 did.
+
+ Predefined tagfmt's (just omit the %l_tag_fmt_ prefix) are:
+
+ - %l_tag_fmt_compat location id (compatible to OpenPKG v1.x) FIXME
+ - %l_tag_fmt_loc location id (improved)
+ - %l_tag_fmt_opt UUID based on with_xxx options
+ - %l_tag_fmt_uuid UUID
+ - %l_tag_fmt_time date and time of build
+ - %l_tag_fmt_user user doing the build
+ - %l_tag_fmt_host host that run the build
+
+ The predefined tagfmt's are not limits, just examples. Use any
+ combination of predefined tags, RPM macros and constants to create
+ a tagfmt, i.e. "<user>binary<opt>at<time>on<host>". Note that the
+ resulting tag can have any character valid for creating a filename
+ but a dash. No error is created for dashes, they are silently
+ removed.
+
+ Keep in mind the tag feature is a function of the bootstrap that is
+ doing the build. An upgrade is run by the existing (old) bootstrap
+ which means that the tag feature is not yet available. Unless you're
+ hacking the rpmmacros file manually, the easiest way to get the tag
+ option on upgrades is to upgrade twice. First to get the new code
+ with the new feature but not using it as the build runs with the
+ old code. Then once again building the new code, this time with the
+ already new code itself, having the feature available.
+
+ There is another reason why an intermediate step will be required
+ during an upgrade, see "Class" header below.
+
+ o new RPM functionality specific to OpenPKG
+
+ "%track" section which will become the new vcheck(1) source
+ "%test" section which will allow run-time testing
+ "Class" header which will become the new package class source
+ See http://cvs.openpkg.org/chngview?cn=14532
+
+ o upgrade procedure with intermediate step
+
+ While RPM silently ignores unknown sections, the introduction of
+ new headers like "Class" inhibits older RPMs from parsing the spec
+ file. Thus an old RPM will refuse to accept packages leveraging
+ such a feature. For all but one packages it means that the OpenPKG
+ bootstrap package "openpkg" has to be upgraded first. The upgrade
+ of the "openpkg" package itself is an exception that requires
+ additional steps.
+
+ FIXME [alternatives listed]
+
+ - we provide an intermediate 2.0.UPGRADE package which can be
+ installed using a 1.x bootstrap. This 2.0.UPGRADE is only
+ supported to fulfill one operation: upgrade to the real 2.0.0
+ bootstrap.
+
+ - install 2.0.0 source RPM, filter the offending header out from the
+ spec and build binary.
+
+ - get ingredients from 2.0.0 source RPM using rpm2cpio, filter the
+ offending header out from the spec and build binary.
+
+ There is another reason why an intermediate step will be required
+ during an upgrade, see "tag" feature above.
Upgrade from OpenPKG 1.2 to OpenPKG 1.3
=======================================
@@ .
______________________________________________________________________
The OpenPKG Project www.openpkg.org
CVS Repository Commit List [EMAIL PROTECTED]
