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]