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: 19-Feb-2004 16:22:48
Branch: HEAD Handle: 2004021915224701
Modified files:
openpkg-re news.txt upgrade.txt
Log:
fix typos; move --db options from upgrade to news; reduce Debian
issues to the minimum and reference full details through a link; add
supported platforms and UUID documentation
Summary:
Revision Changes Path
1.31 +304 -21 openpkg-re/news.txt
1.25 +52 -113 openpkg-re/upgrade.txt
____________________________________________________________________________
patch -p0 <<'@@ .'
Index: openpkg-re/news.txt
============================================================================
$ cvs diff -u -r1.30 -r1.31 news.txt
--- openpkg-re/news.txt 17 Feb 2004 22:55:35 -0000 1.30
+++ openpkg-re/news.txt 19 Feb 2004 15:22:47 -0000 1.31
@@ -2,7 +2,7 @@
General Note
============
- o $Revision: 1.30 $. The most recent update of this file can be
+ o $Revision: 1.31 $. 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
@@ -17,11 +17,12 @@
o OpenPKG 1.1: {s,m,r,n}{usr,grp}, sane build env., with_xxx options, proxy
packages
o OpenPKG 1.2: %option, OSSP fsl (I), Perl 5.8, openpkg-perl.sh+site_perl,
openpkg-tool
o OpenPKG 1.3: GCC 3.3, OSSP fsl (II), worked-off RC facility
- o OpenPKG 2.0: %track, Class:, RPM 4.2, shtool plaform, OSSP uuid, tags,
openpkg-perl.pl+vendor_perl
+ o OpenPKG 2.0: %track, Class:, RPM 4.2, shtool platform, OSSP uuid, tags,
openpkg-perl.pl+vendor_perl
Essentials about OpenPKG 2.0
============================
+ o Major Release
o Bootstrap Package ("openpkg"):
- upgraded from RPM 4.0.4 to RPM 4.2.1
- new RPM DB format (upgrade from Berkeley DB 3.2 to 4.1)
@@ -32,30 +33,29 @@
- more accurate removal of all temporary build files
- new "rpm -bb --short-circuit"
- "rpm -bs" no longer requires source dependencies
- - new "%track" section (containing the vcheck(1) configs) and "rpm --track"
- - new "%test" section (for forthcoming test suites) and "rpm --test"
+ - new "%track" section replaces vc.* files
+ - new "%test" section test [unused, reserved for future use] for quality
assurance
- new "Class:" header (for CORE,BASE,PLUS,EVAL,JUNK tagging)
- new platform identification (via our GNU shtool 2.0's new 'platform' command)
- platform and instance identification via UUID (via our new OSSP uuid toolkit)
- - new convinience CLI options "--with <name>" and "--without <name>"
+ - new convenience CLI options "--with <name>" and "--without <name>"
- RPM now internally uses transactions
- RPM now is able to perform concurrently (allowing RPM to be called from RPM)
- - most of the CORE packages are OpenPKG "branded" now
+ - many of the CORE packages are OpenPKG "branded" now
- the RPM C API is installed and available via "rpm-config" utility
- new --tar option eases extraction of shell archive ingredients aiding
recovery activities
o Upgraded to Perl 5.8.3 and completely worked off Perl module packaging
(perl-openpkg)
o Completely worked off Run-Command (RC) facility now also for PLUS and EVAL
class packages.
o All packages were upgraded to their latest vendor versions as of YX-Feb-2004.
- o Increased release class packages from 400 (in OpenPKG 1.3) to now 474
- o Increased number of supported platforms to XX
+ o Increased release class packages from 400 (in OpenPKG 1.3) to now 473
o Thousands of packaging bugfixes and vendor source code portations
Major changes between OpenPKG 1.3 and OpenPKG 2.0
=================================================
- o Major Version
+ o Major Release
- OpenPKG version numbering is driven by technical enhancements and
+ OpenPKG release numbering is driven by technical enhancements and
release engineering requirements, not by marketing. The technical
change is that we now have RPM 4.2.1 under the hood. The engineering
changes are (for the time being) the discontinuation of a STABLE
@@ -63,17 +63,281 @@
will experience a flat learning curve when he starts working with
the new 2.0 release.
+ o Supported Platforms
+
+ OpenPKG 2.0 fully supports the following platforms and
+ provides binaries of packages from the CORE+BASE classes.
+
+ ix86-freebsd4.9 FreeBSD 4.9
+ ix86-freebsd5.2 FreeBSD 5.2
+ ix86-debian3.0 Debian GNU/Linux 3.0
+ ix86-debian3.1 Debian GNU/Linux 3.1
+ ix86-fedora1 Red Hat Fedora Core 1
+ ix86-rhel3 Red Hat Enterprise Linux 3
+ ix86-suse9.0 SuSE Linux 9.0
+ ix86-solaris9 Sun Solaris 9
+ sparc64-solaris8 Sun Solaris 8
+ sparc64-solaris9 Sun Solaris 9
+ ix86-solaris10 Sun Solaris 10
+
+ OpenPKG 2.0 also supports the following platforms and
+ provides binaries of packages from the CORE class.
+
+ ix86-debian2.2 Debian GNU/Linux 2.2
+ ix86-rhl9 Red Hat Linux 9
+ ix86-suse8.2 SuSE Linux 8.2
+ ix86-gentoo1.4.3 Gentoo Linux 1.4
+ sparc64-solaris2.6 Sun Solaris 2.6
+
+ OpenPKG 2.0 does not come with binaries for other platforms.
+ No binaries are provided for PLUS packages.
+ Updates are only available as source packages.
+
+ Packages with a class different from CORE, BASE, PLUS are not part
+ of the release. They are only available as CURRENT source packages.
+
+ o new prefix for binary packages
+
+ OpenPKG 2.0 comes with binaries build for /openpkg prefix.
+ Previously they were build for /cw prefix.
+
+ o new command line interface
+
+ The official command line user interface to rpm is the new
+ %{l_prefix}/bin/openpkg command multiplexer with the "rpm"
+ subcommand. The direct execution of %{l_prefix}/bin/rpm is
+ deprecated. For more information see "%{l_prefix}/bin/rpm and
+ %{l_prefix}/bin/rpm2cpio deprecated" in news.txt file.
+
+ o new RPM header
+
+ - Class: header to specify status, one of CORE,BASE,PLUS,EVAL,JUNK
+ See http://cvs.openpkg.org/chngview?cn=14532
+
+ o new RPM sections
+
+ - %track contains version tracking information and replaces vc.*
+ files previously stored in separate files in the release
+ engineering area of the CVS repository.
+
+ $ %{l_prefix}/bin/openpkg rpm --track
+
+ - %test [unused, reserved for future use] for quality assurance.
+
+ $ %{l_prefix}/bin/openpkg rpm --test
+
+ o new tag feature
+
+ 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 UUID feature
+
+ OpenPKG 2.0 creates three universal unique identifiers (UUIDs) for
+ every instance and stores them in the %{l_prefix}/etc/openpkg/uuid
+ file using a very easy to parse key="value" format. The file can be
+ sourced from a shell to set the three variables. Example:
+
+ UUID_REGISTRY="0e046c16-6252-11d8-8277-000d9d9784cf"
+ UUID_INSTANCE="db1733cb-b4f1-3d40-9b6b-0eb4dfec965b"
+ UUID_PLATFORM="61a4580d-b45c-388f-a9b9-9887780a8b2d"
+
+ The three UUIDs can be used to uniqely and ultimately identify a
+ OpenPKG instance. Currently OpenPKG does not use this information
+ unless you explictly tell it to do so. It provides the information
+ to enable additional services and functionality in the future. A
+ typical application is to use the UUIDs as the key to identify an
+ instance in a enterprise software inventory.
+
+ UUID_REGISTRY is based on time and node address. It is unique
+ for every installation. A bootstrap (re)installed multiple times
+ will never yield the same UUID. This ID is updated only during
+ installation or after the ID was reset to zero. If you do not want
+ to leak the node address information, reset and run the update
+ process manually and enforce node address to be replaced by random
+ multicast address, as descibed below.
+
+ UUID_INSTANCE is based on instance related information like prefix
+ and user ids. All installations having exactly the same paramters
+ will have the same UUID. This ID is updated during installation,
+ on every system startup (rc.openpkg %start) and daily (rc.openpkg
+ %daily). Can be used to detect if a
+
+ UUID_PLATFORM is based on host name and network information. All
+ installations having exactly the same paramters will have the same
+ UUID. This ID is updated during installation, on every system
+ startup (rc.openpkg %start) and daily (rc.openpkg %daily). Can be
+ used to detect relocated instances or instances on mobile platforms.
+
+ We understand that the provisioning of UUIDs is not welcome by
+ everybody. People tend to be afraid
+
+ - which data is used to create the UUID
+ - where it is send to
+ - how much information can be recovered by the recipient
+
+ We provide a way for the user to reproduce how the UUIDs are
+ generated. Full transparency here.
+
+ Currently OpenPKG does not send the data anywhere. It is not used
+ by OpenPKG. We believe OpenPKG takes the open source concept to the
+ extreme (i.e. we provide public access to our CVS which contains
+ forthcoming press releases and all the code of our web site) and
+ this ensures our work is transparent. It is easy to verify we do not
+ include code to send the data anywhere.
+
+ A UUID can be made up of input data and/or randomness. We provide a
+ way for the user to decode UUIDs. Full transparency here.
+
+ The UUID needs of OpenPKG triggered the creation of OSSP uuid which
+ is included in the bootstrap. To reproduce how the UUIDs were
+ generated and to see which information can be decoded. The user
+ might run one of two alternatives:
+
+ $ %{l_prefix}/etc/rc openpkg info
+ $ %{l_prefix}/bin/openpkg uuid info
+
+ OpenPKG Summary of Identification Information
+ =============================================
+
+ OpenPKG Registry
+ System Time: 2004-02-18 20:35:56.944079.0 UTC
+ System Clock Sequence: 631 (usually random)
+ System Node Address: 00:0d:9d:97:84:cf (global unicast)
+ UUID_REGISTRY: 0e046c16-6252-11d8-8277-000d9d9784cf
+
+ OpenPKG Instance
+ Release: OpenPKG-2.0
+ Prefix: /openpkg
+ Super Account: root(0):wheel(0)
+ Management Account: openpkg(42000):openpkg(42000)
+ Restricted Account: openpkg-r(42001):openpkg-r(42001)
+ Nonprivileged Account: openpkg-n(42002):openpkg-n(42002)
+ UUID_INSTANCE: db1733cb-b4f1-3d40-9b6b-0eb4dfec965b
+
+ OpenPKG Platform
+ Platform Id: ix86-freebsd4.9
+ Host Name: dv1.dev.de.cw.net
+ Host IP Address #1 127.0.0.1
+ Host IP Address #2 141.1.23.34
+ Host IP Address #3 ::1
+ Host IP Address #4 fe80::1%lo0
+ Host IP Address #5 fe80::20d:9dff:fe97:84ce%bge1
+ Host IP Address #6 fe80::20d:9dff:fe97:84cf%bge0
+ UUID_PLATFORM: 61a4580d-b45c-388f-a9b9-9887780a8b2d
+
+ It should be pointed out that time based UUID Registry can never be
+ reproduced completely. That's what UUIDs were invented for. However,
+ you can manually reset to zero and update with multicast to hide the
+ node address. This change is visible. The input based UUIDs Instance
+ and Platform can be reproduced completely. However, the algorithm to
+ create a UUID from input is a message digest (MD5) function which
+ does not allow to extract the original information from the UUID. At
+ best it can be used to compare with another UUID created with known
+ input. More details can be learned by running the following UUID
+ related commands with the --verbose option.
+
+ - reset UUID by zeroing out data. Useful before update or to prepare
+ a machine before cloning the hard disk drive.
+
+ $ %{l_prefix}/bin/openpkg uuid reset
+
+ - update UUID. Same what rc.openpkg %start and %daily do. Alters
+ Registry only when reset to zero. Writes file only when Registry,
+ Instance or Platform changed, so time stamp can be monitored.
+
+ $ %{l_prefix}/bin/openpkg uuid update
+ $ %{l_prefix}/bin/openpkg uuid -m update #multicast
+
+ - query UUID information. See "Summary of Identification
+ Information" above.
+
+ $ %{l_prefix}/bin/openpkg uuid info
+
o Extensions to RPM 4.2.1:
- --db-{build,rebuild,cleanup,fixate}
- accurate removal of temporary files
- -bb --short-circuit
- [TODO] %track section (old vcheck files vc.*)
- [TODO] %test section (for forthcoming test suites)
- [TODO] Class: header (for CORE,BASE,PLUS,EVAL,JUNK)
- ...FIXME...
+ - accurate removal of temporary files
+
+ - ability to short-circuit from -bi to -bb step
+
+ $ %{l_prefix}/bin/openpkg rpm -bb --short-circuit
+
+ o RPM DB administration
+
+ A new <prefix>/lib/openpkg/rpmdb utility is available for
+ administrating the RPM database on the lower level.
- o Upgraded from RPM 4.0.2 to RPM 4.2.1.
+ Build new RPM DB. This is a destructive operation. You have to know
+ what you are doing.
+
+ $ %{l_prefix}/bin/openpkg rpm --db-build
+
+ Rebuild new from old database. Reasonable after upgrades or on DB
+ corruption.
+
+ $ %{l_prefix}/bin/openpkg rpm --db-rebuild
+
+ Cleanup existing database. Reasonable after DB out-of-sync
+ situations.
+
+ $ %{l_prefix}/bin/openpkg rpm --db-cleanup
+
+ Fixate existing database. Harmless operation. Fixating files only.
+
+ $ %{l_prefix}/bin/openpkg rpm --db-fixate
+
+ o Features inherited from RPM 4.0.2 to RPM 4.2.1 upgrade
- Query Pattern Matching
@@ -107,7 +371,7 @@
RPM 4.2 now uses the BeeCrypt cryptography library for verification
of signatures. Previously one needed an externally available GnuPG.
GnuPG now is only needed for creating signatures. Additionally, RPM
- 4.2 manages OpenPGP publuc keys in its RPM database similar to real
+ 4.2 manages OpenPGP public keys in its RPM database similar to real
packages (they even can be seen as pseudo-packages "gpg-pubkey-XXXXX"
under query operations). The OpenPKG bootstrap (and also the regular
upgrade procedure) now especially imports the OpenPKG OpenPGP public
@@ -140,7 +404,7 @@
RPM 4.2 now uses an enhanced version of the POPT library, which
especially allows special "argument eating" markers "!#:+" to be
- used in the rpmpopt file. This allowed us now to provide convinience
+ used in the rpmpopt file. This allowed us now to provide convenience
macros for %option handling on the command line:
--with foo => --define 'with_foo yes' => %option with_foo yes
@@ -227,6 +491,25 @@
FIXME http://www.openpkg.org/cvs.png needs be fixed.
+ o new ndbm behaviour
+
+ Vendors begin to remove ndbm from their distributions.
+ Debian 3.1 (sarge) is known to be one of them. OpenPKG
+ 2.0 uses its ndbm compatiblity provided by gdbm. See
+ http://cvs.openpkg.org/chngview?cn=14710
+
+ o Debian 3.1 (sarge) install-info causing info.dir trouble
+
+ 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
+ is to have the Debian install-info either not installed at all or
+ temporary replaced by /bin/true, i.e. using:
+
+ # mv /usr/sbin/install-info /usr/sbin/install-info.debian
+ # ln -s /bin/true /usr/sbin/install-info
+
o New platform identification (%{l_platform})
...FIXME...
@@ -452,7 +735,7 @@
3. run "openpkg build -Ua | sh -" to actually update your instance.
- 4. For convinience reasons you can pre-config options in
+ 4. For convenience reasons you can pre-config options in
$HOME/.openpkg/build. My rc file on en1 for instance looks like:
| -R /usr/opkg/bin/rpm
@@ .
patch -p0 <<'@@ .'
Index: openpkg-re/upgrade.txt
============================================================================
$ cvs diff -u -r1.24 -r1.25 upgrade.txt
--- openpkg-re/upgrade.txt 19 Feb 2004 09:56:00 -0000 1.24
+++ openpkg-re/upgrade.txt 19 Feb 2004 15:22:48 -0000 1.25
@@ -2,7 +2,7 @@
General Notes
=============
- o $Revision: 1.24 $. The most recent update of this file can be
+ o $Revision: 1.25 $. 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
@@ -38,13 +38,17 @@
Upgrade from OpenPKG 1.3 to OpenPKG 2.0
=======================================
- o RPM 4.0.2 to 4.2.1:
+ o one way ticket
- you can't go back and require a --db-rebuild afterwards!
+ Upgrading the bootstrap from RPM 4.0.2 based OpenPKG 1.3 to RPM
+ 4.2.1 based OpenPKG 2.0 is irreversible. You can't go back!
+
+ o database conversion
- o if RPM hangs during installation of a package or you get a
- "Resource temporarily unavailable", it's time for --db-rebuild
+ After upgrading you must run --db-rebuild.
+ o RPM hangs or reports "Resource temporarily unavailable"
+
Be sure no rpm process is hanging around and locking the database.
$ /cw/bin/rpm --db-rebuild
@@ -56,30 +60,6 @@
rpmdb: performing read/write operation on RPM database
rpmdb: making sure RPM database files have consistent attributes
- More background information from openpkg.spec log (revision 1.219):
- Completely revamp the RPM database fiddling:
-
- Introduce new <prefix>/lib/openpkg/rpmdb utility for administrating
- the RPM database on the lower level and hook it into the
- <prefix>/bin/rpm command line with four options:
-
- --db-build RPM database administration: build new
- database (destructive operation; you have
- to know what you are doing)
-
- --db-rebuild RPM database administration: rebuild new
- from old database (upgrading operation;
- reasonable after upgrades or on DB
- corruption)
-
- --db-cleanup RPM database administration: cleanup
- existing database (cleaning operation;
- reasonable after DB out-of-sync situations)
-
- --db-fixate RPM database administration: fixate
- existing database (harmless operation; for
- fixating files only)
-
o the following options were renamed
OpenPKG v1.3 OpenPKG 2.0
@@ -96,115 +76,74 @@
with_openssl with_ssl
with_tls with_ssl
- o ndbm
+ o new ndbm behaviour
Vendors begin to remove ndbm from their distributions. Debian 3.1
- (sarge) is known to be one of them. Go the OpenPKG independence
- way and use own ndbm compatiblity provided by gdbm. This might
- break existing installations due to gdbm_ndbm not being file format
- 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
+ (sarge) is known to be one of them. OpenPKG 2.0 uses its ndbm
+ compatiblity provided by gdbm.
+
+ However, installations mixing vendor and OpenPKG stuff and
+ existing installations upgrading might run into trouble. The
+ reason is that gdbm::with_ndbm supports a ndbm API, makes
+ 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
+ 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
+ unable to read old ndbm and accidentally grant access). Both
+ 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.
+ See http://cvs.openpkg.org/chngview?cn=14523
+
+ Upgraders have two options:
+
+ 1.) build gdbm with_ndbm=no and build apache with_gdbm_ndbm=no.
+ This reverts to the old behaviour of using the vendor ndbm
+ and, of course, only works on OS that provide one.
+
+ 2.) convert/recreate your ndbm databases.
o axed out the support for the obsoleted PHP3
suPHP can be use on legacy setups.
- 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
+ the new "Class:" header 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.
+ - we provide an intermediate openpkg-1.9.9-2.0.0.src.rpm (no src.sh)
+ package which can be installed using a 1.x bootstrap. This
+ intermediate package 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
+ - install 2.0.0 source RPM, filter the offending "Class:" 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.
+ o new tag feature to replace location id
+
+ Using an intermediate step during an upgrade allows the new tag
+ feature to be engaged for the bootstrap. See "new tag feature" in
+ news.txt file.
o %{l_prefix}/bin/rpm and %{l_prefix}/bin/rpm2cpio deprecated
Direct execution of %{l_prefix}/bin/rpm and %{l_prefix}/bin/rpm2cpio
- is deprecated. The binaries were relocated. Switch to using the new
- %{l_prefix}/bin/openpkg command multiplexer and use the appropriate
- subcommand, i.e.
+ is deprecated. The executable binaries were relocated. Switch to
+ using the new %{l_prefix}/bin/openpkg command multiplexer and use
+ the appropriate subcommand, i.e.
$ /13/bin/rpm -qi openpkg
$ /20/bin/openpkg rpm -qi openpkg
@@ -268,7 +207,7 @@
- openpkg-tool is available as CURRENT package
- o package version numbering changes
+ o package version numbering changed
OpenPKG uses a package naming scheme that starts with
<name>-<version>-<release>. Details can be reviewed at
@@ .
______________________________________________________________________
The OpenPKG Project www.openpkg.org
CVS Repository Commit List [EMAIL PROTECTED]
