head 1.54; access; symbols OPENPKG_CW_FP:1.53; locks; strict; comment @# @; 1.54 date 2005.06.22.08.16.39; author thl; state Exp; branches; next 1.53; 1.53 date 2005.02.24.16.23.09; author thl; state Exp; branches; next 1.52; 1.52 date 2004.11.04.08.50.18; author thl; state Exp; branches; next 1.51; 1.51 date 2004.10.20.15.59.42; author rse; state Exp; branches; next 1.50; 1.50 date 2004.10.20.15.57.35; author rse; state Exp; branches; next 1.49; 1.49 date 2004.10.20.14.22.30; author thl; state Exp; branches; next 1.48; 1.48 date 2004.07.20.08.00.16; author rse; state Exp; branches; next 1.47; 1.47 date 2004.07.07.07.54.10; author thl; state Exp; branches; next 1.46; 1.46 date 2004.06.29.07.38.48; author thl; state Exp; branches; next 1.45; 1.45 date 2004.06.22.09.00.17; author thl; state Exp; branches; next 1.44; 1.44 date 2004.06.22.08.46.11; author thl; state Exp; branches; next 1.43; 1.43 date 2004.05.15.20.49.11; author thl; state Exp; branches; next 1.42; 1.42 date 2004.03.24.16.31.38; author thl; state Exp; branches; next 1.41; 1.41 date 2004.03.15.22.18.03; author thl; state Exp; branches; next 1.40; 1.40 date 2004.03.13.22.27.43; author thl; state Exp; branches; next 1.39; 1.39 date 2004.03.13.22.04.06; author thl; state Exp; branches; next 1.38; 1.38 date 2004.03.13.21.42.16; author thl; state Exp; branches; next 1.37; 1.37 date 2004.03.13.21.30.05; author thl; state Exp; branches; next 1.36; 1.36 date 2004.03.10.10.31.58; author cs; state Exp; branches; next 1.35; 1.35 date 2004.02.26.07.52.53; author thl; state Exp; branches; next 1.34; 1.34 date 2004.02.26.07.51.11; author thl; state Exp; branches; next 1.33; 1.33 date 2004.02.25.20.47.10; author rse; state Exp; branches; next 1.32; 1.32 date 2004.02.25.10.13.39; author thl; state Exp; branches; next 1.31; 1.31 date 2004.02.23.14.53.10; author thl; state Exp; branches; next 1.30; 1.30 date 2004.02.20.15.18.36; author thl; state Exp; branches; next 1.29; 1.29 date 2004.02.20.14.04.57; author thl; state Exp; branches; next 1.28; 1.28 date 2004.02.20.11.50.39; author thl; state Exp; branches; next 1.27; 1.27 date 2004.02.20.09.29.22; author thl; state Exp; branches; next 1.26; 1.26 date 2004.02.19.16.00.40; author thl; state Exp; branches; next 1.25; 1.25 date 2004.02.19.15.22.48; author thl; state Exp; branches; next 1.24; 1.24 date 2004.02.19.09.56.00; author thl; state Exp; branches; next 1.23; 1.23 date 2004.02.17.14.09.50; author thl; state Exp; branches; next 1.22; 1.22 date 2004.02.03.09.14.47; author thl; state Exp; branches; next 1.21; 1.21 date 2004.01.30.20.25.49; author thl; state Exp; branches; next 1.20; 1.20 date 2004.01.30.09.26.03; author thl; state Exp; branches; next 1.19; 1.19 date 2004.01.20.23.59.45; author thl; state Exp; branches; next 1.18; 1.18 date 2004.01.16.09.31.17; author thl; state Exp; branches; next 1.17; 1.17 date 2003.10.08.07.47.07; author thl; state Exp; branches; next 1.16; 1.16 date 2003.10.07.07.18.37; author thl; state Exp; branches; next 1.15; 1.15 date 2003.10.05.13.37.50; author rse; state Exp; branches; next 1.14; 1.14 date 2003.08.06.11.08.54; author rse; state Exp; branches; next 1.13; 1.13 date 2003.08.04.11.27.16; author thl; state Exp; branches; next 1.12; 1.12 date 2003.07.31.19.53.21; author thl; state Exp; branches; next 1.11; 1.11 date 2003.07.31.14.46.56; author thl; state Exp; branches; next 1.10; 1.10 date 2003.07.31.14.42.38; author thl; state Exp; branches; next 1.9; 1.9 date 2003.07.31.10.46.23; author thl; state Exp; branches; next 1.8; 1.8 date 2003.07.31.09.07.30; author thl; state Exp; branches; next 1.7; 1.7 date 2003.07.31.08.22.06; author thl; state Exp; branches; next 1.6; 1.6 date 2003.07.30.12.17.01; author thl; state Exp; branches; next 1.5; 1.5 date 2003.07.30.09.36.59; author thl; state Exp; branches; next 1.4; 1.4 date 2003.07.30.09.34.40; author thl; state Exp; branches; next 1.3; 1.3 date 2003.07.23.12.03.17; author thl; state Exp; branches; next 1.2; 1.2 date 2003.07.23.08.19.12; author thl; state Exp; branches; next 1.1; 1.1 date 2002.12.04.09.59.06; author rse; state Exp; branches; next ; desc @@ 1.54 log @add/uprev OpenPKG 2.4 @ text @ Upgrade Notes ============= o $Revision: 1.53 $. The most recent update of this file can be downloaded from http://cvs.openpkg.org/openpkg-re/upgrade.txt Typical practice upgrading to a new OpenPKG RELEASE =================================================== o Information Become familiar with the vendor documentation of your favorite applications and the OpenPKG release notes. The latter can be downloaded from http://cvs.openpkg.org/openpkg-re/releasenotes.txt. o Backup Backup your data and configuration. The new release might ship a new incompatible vendor version of your favorite application. In the worst case it might render your data invalid when running it against old data without proper conversion. On installation of binaries OpenPKG rpm might move your configuration files away into backup files named with .rpmsave suffix. This means your customization is gone and the application reverts to the OpenPKG default. Existence of such backup files inhibits daemons from getting started. You must manually merge or copy back your customization and get rid of the backup files. WARNING: when remotely upgrading OpenPKG's "openssh" package make sure you do not leave the shell unless you ensured it did not revert to default behavior which includes deadly denial of root login and listening to local address only. o Cleanup Building OpenPKG requires approximately 300MB of disk space on the filesystem holding the source and temporary areas. Some packages are known to use an equal amount of space during build like gcc, some have even larger requirements like mozilla and qt. Unless RPM macros %_sourcedir, %_specdir, %_builddir and %_tmppath have been overridden the default place is $PREFIX/RPM/SRC and $PREFIX/RPM/TMP. Assuming you use these places in their intended form it is safe to delete all data from them to cleanup relicts from previous rebuilds. o OpenPKG (bootstrap) Rebuild the new "openpkg" (bootstrap) package using the existing one. Something like $ $PREFIX/bin/openpkg rpm --rebuild \ ftp://ftp.openpkg.org/release/2.4/SRC/openpkg-2.4.0-2.4.0.src.rpm will do the job, then install the resulting binary using $ $PREFIX/bin/openpkg rpm -Uvh \ $PREFIX/RPM/PKG/openpkg-2.4.0-2.4.0.*-*.rpm o Devtools Upgrade the development tools. Start with "make", "binutils" and "gcc". o Build Install "perl" and "openpkg-tools". This enables the "openpkg build" command. Use it to compute a shell script formatted list of rebuild and install action pairs ordered by dependency requirements and annotated with optional defines you used to create the existing installation. $ $PREFIX/bin/openpkg build -Ua | tee todo.sh Review this script. It is a good idea to move all the worthy applications, the ones you actually use OpenPKG for and not their dependencies, to the end of the script and deactivate their installation by commenting out parts of the script. You can run the build of all packages and the installation of dependency tools unattended. This might take hours. o Finalize Come back later and run the installation of the worthy applications manually. Watch for ".rpmsaves", resolve them and restart the daemons. @ 1.53 log @update examples in upgrade procedure @ text @d5 1 a5 1 o $Revision: 1.52 $. The most recent update of this file can be d52 1 a52 1 ftp://ftp.openpkg.org/release/2.3/SRC/openpkg-2.3.0-2.3.0.src.rpm d57 1 a57 1 $PREFIX/RPM/PKG/openpkg-2.3.0-2.3.0.*-*.rpm @ 1.52 log @add note about required disk space and ways to cleanup @ text @d5 1 a5 1 o $Revision: 1.51 $. The most recent update of this file can be d52 1 a52 1 ftp://ftp.openpkg.org/release/2.2/SRC/openpkg-2.2.0-2.2.0.src.rpm d57 1 a57 1 $PREFIX/RPM/PKG/openpkg-2.2.0-2.2.0.*-*.rpm @ 1.51 log @add path @ text @d5 1 a5 1 o $Revision: 1.50 $. The most recent update of this file can be d35 11 @ 1.50 log @better fitting headline @ text @d5 1 a5 1 o $Revision: 1.49 $. The most recent update of this file can be d45 2 a46 1 $ $PREFIX/bin/openpkg rpm -Uvh openpkg-2.2.0-2.2.0.*-*.rpm @ 1.49 log @Typical practice upgrading to a new OpenPKG RELEASE @ text @d2 1 a2 1 General Notes d5 1 a5 1 o $Revision: 1.48 $. The most recent update of this file can be @ 1.48 log @fix typo @ text @d5 1 a5 1 o $Revision: 1.47 $. The most recent update of this file can be d8 65 a72 4 o This file upgrade.txt file talked about tweaks and quirks when upgrading, common pitfalls and ways to bypass them. It was replaced by the new "Release Notes" document which can be downloaded from http://cvs.openpkg.org/openpkg-re/releasenotes.txt @ 1.47 log @consolidate news.txt and upgrade.txt into new releasenotes.txt moving content verbatim; news.txt retains some high level overview information, upgrade.txt is completely obsolete @ text @d5 1 a5 1 o $Revision: 1.46 $. The most recent update of this file can be d11 1 a11 1 http://cvs.openpkg.org/openpkg-re/relesenotes.txt @ 1.46 log @start working on news and upgrade information about OpenPKG 2.1 @ text @d5 1 a5 1 o $Revision: 1.45 $. The most recent update of this file can be d8 4 a11 1322 o This file upgrade.txt file talks about tweaks and quirks when upgrading. It lists common pitfalls and ways to work around them. To receive information about new features and major improvements read the companion news.txt document. 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. Upgrade from OpenPKG 2.0 to OpenPKG 2.1 ======================================= o new openpkg-tools package This new package provides tools for administrators and developers and contains code known from the former openpkg-tool package. o packages dropped from release - autogen downgraded to EVAL because of portability problems, available from CURRENT Upgrade from OpenPKG 1.3 to OpenPKG 2.0 ======================================= o one way ticket 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 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. $ %{l_prefix}/bin/openpkg rpm --db-rebuild rpmdb: REBUILDING NEW FROM OLD RPM DATABASE (/cw/RPM/DB) rpmdb: cleaning up RPM database DB region files rpmdb: making sure RPM database contains all possible DB files rpmdb: dumping and reloading RPM database DB file contents rpmdb: rebuilding RPM database (built-in RPM procedure) rpmdb: performing read/write operation on RPM database rpmdb: making sure RPM database files have consistent attributes o RPM reports "Resource temporarily unavailable" during build The OpenPKG build process restricts itself from consuming too much resources by setting ulimit(1) through the %{l_build_ulim} macro. This can lead to situations where the build of a package breaks at arbitrary points. If you want to modify the limits redefine the macro. For no limits set the macro to %nil in the building user's ~/.rpmmacros. $ echo "%l_build_ulim %nil" >>%{l_prefix}/.rpmmacros o openssh does not restart after upgrade The OpenSSH daemon in OpenPKG 1.3 uses a different pid file than the one in 2.0. The postinstall scriptlet running at the end of the install process belongs to 2.0, does not find the previous pid file and is unable to stop the old daemon. As a result it cannot start the new daemon. Workaround is to either stop the old daemon before the installation or to kill the old daemon manually. In both cases the new daemon has to be started manually. $ %{l_prefix}/etc/rc openssh start status o the following options were renamed OpenPKG 1.3 OpenPKG 2.0 --------------------- ----------------- with_berkeleydb with_bdb with_db with_bdb with_db_postgresql with_db_pgsql with_dbd_pg with_dbd_pgsql with_innobase with_innodb with_mod_php3_openssl with_mod_php3_ssl with_mod_php_db with_mod_php_bdb with_mod_php_openssl with_mod_php_ssl with_mod_php_unixodbc with_mod_php_odbc with_openssl with_ssl with_tls with_ssl o new ndbm behavior 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 compatibility 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 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 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 2.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 used on legacy setups. o upgrade procedure with intermediate step While RPM silently ignores unknown sections, the introduction of the new "Class:" header inhibits older RPMs from parsing the spec file. Therefore the bootstrap package "openpkg" has to be upgraded first using one of the following variants: - use openpkg-1.3.1 to rebuild and install the openpkg-1.9.0-2.0.0.src.rpm provided with the 2.0 release (intentionally no src.sh available). This intermediate package is a modified openpkg-2.0.0-2.0.0.src.rpm that has the offending "Class:" header removed. This is the recommended variant. For updated >= openpkg-2.0.1-2.0.1 corresponding companion >= openpkg-1.9.1-2.0.1 are available. - use openpkg-1.3.1 to install openpkg-2.0.0-2.0.0.src.rpm, manually filter out the offending "Class:" header. Then build and install it using openpkg-1.3.1. - use rpm2cpio to get ingredients from openpkg-2.0.0-2.0.0.src.rpm, manually filter out the offending "Class:" header. Then build and install it using openpkg-1.3.1. The last step of upgrading the "openpkg" package is to use the 1.9 aka "Class:"-less 2.0 bootstrap to rebuild and install the real openpkg-2.0.0-2.0.0.src.rpm. At this point the upgrade reaches a point indistinguishable from a fresh install. Note that a 1.x installation is not able to read 2.x binary RPMs. When upgrading, it is a requirement using openpkg-1.3.1 to build the 1.9 aka "Class:"-less 2.0 bootstrap binary RPM. If you use a build host to create binaries and deploy them on target machines make sure the build host runs openpkg-1.3.1 when creating the intermediate package and the build host runs openpkg-2.0.0 when creating the real package. Deploy the intermediate then the real bootstrap to the target machines. Do not skip the intermediate step. o error "Unknown tag: Class" The message appears when a bootstrap is not aware of the new "Class:" header and is given a spec file which makes use of this new feature. Upgrade the bootstrap. If the problem is building the bootstrap during upgrade you probably tried to skip the intermediate step. 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 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 to provide full backwards compatibility to existing %{l_location}. 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. o perl and modules All additional modules install into vendor_perl not site_perl. o perl-openpkg The perl-openpkg Perl implementation is incompatible to it's predecessor. After perl-openpkg is upgraded old perl-* modules and packages providing perl modules can no longer be build. OpenPKG 2.0 packages must be used. 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 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 # <= OpenPKG 1.3 $ /20/bin/openpkg rpm -qi openpkg # >= OpenPKG 2.0 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 2.1 will discontinue support for these wrappers and any legacy application will fail unless it is properly updated. o supporting calls to rpm in both OpenPKG v1.x and 2.x Developers note that checking for bin/openpkg and libexec/openpkg is necessary to detect 2.x because 1.x provided an incompatible bin/openpkg through the openpkg-tool package /bin/rpm | /bin/openpkg | | /libexec/openpkg/rpm | | | 0 0 0 no OpenPKG installed 0 0 1 N/A 0 1 0 N/A 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 2.0 with /bin/rpm compatibility wrapper 1 x 0 OpenPKG v1.x x 1 1 OpenPKG v2.x o %{l_prefix}/bin/openpkg vs. openpkg-tool In OpenPKG v1.x a %{l_prefix}/bin/openpkg subcommand multiplexer was provided as part of the openpkg-tool package. It had two subcommands "index" and "build". In OpenPKG v2.x the %{l_prefix}/bin/openpkg multiplexer was rewritten from scratch and became part of the bootstrap. It's power comes from the fact that it allows packages to provide additional subcommands to be plugged in and overload default subcommands. Because the old openpkg-tool and the new bootstrap provide the same file they conflict with each other and their use is mutually exclusive. It is therefore imperative to erase the old openpkg-tool package before upgrading. After the upgrade a new openpkg-tools package can be installed which was revamped to provide "index" and "build" plug ins. This effectively hides the change for normal use, i.e. $ /13/bin/openpkg build -Ua # <= OpenPKG 1.3 $ /20/bin/openpkg build -Ua # >= OpenPKG 2.0 However, access to the manual page(s) changed and will only work after the CURRENT version of openpkg-tools has been installed. 13$ man openpkg 20$ openpkg man index 20$ openpkg man build o packages dropped from release - freetype1 replaced by freetype package containing freetype2 - gcc32 obsoleted - openpkg-tool replaced by CURRENT openpkg-tools package - tinyca requires gnome which is not available in OpenPKG o package version numbering changed OpenPKG uses a package naming scheme that starts with --. Details can be reviewed at http://www.openpkg.org/cvs.txt, they did not change although OpenPKG 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 OS components (i.e. x11), bundle multiple vendor versions (i.e. perl-*, infozip) and metapackges which only provide requirements. In OpenPKG v1.x these packages had version=release both in CURRENT (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 unnecessarily hard. Adjusting the version 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: - Packages that only reference existing OS components have the version changed to constant zero, see http://cvs.openpkg.org/chngview?cn=14942 kde meta-* openpkg-import oracle pam sgml x11 - Packages with perl modules belong to Perl and have the version changed to that of the perl package they belong to, see http://cvs.openpkg.org/chngview?cn=14937 perl-* - Packages which are bundles that have no real "master" version; first solution: concatenate versions, see http://cvs.openpkg.org/chngview?cn=14938 infozip - Packages which are bundles that have no real "master" version; second solution: manually maintain version only (only is new) whenever one of the vendor version changes. openpkg-tool, kolab In all cases of packages and branches the release is now maintained independent of the version. Some of these changes make RPM think it performs a downgrade, so --oldpackage might be required during an upgrade, see old "RPM downgrade view" issue below. Example: 13> pam-20030715-1.3.0.src.rpm (accident) 13> pam-1.3.1-1.3.1.src.rpm 20> pam-0-2.0.0.src.rpm o packages with OpenPKG number appended In case one of the upgrade candidates has a OpenPKG - not a vendor - version number in it's name it is time to review and understand "What are physical/virtual/replacement/alternative packages" in FAQ http://www.openpkg.org/faq.html#package-type. For example, bind and bind8 are different packages where OpenPKG maintains two major vendor versions at the same time. Similar logic applies to gcc/gcc32 and mysql3/mysql/mysql41. The following packages naturally have a digit in their name and are not subject to replacement/alternative packages: - bzip2 - crm114 - glib2 - gtk2 - its4 - libtasn1 - pgp2 o recommended manual upgrade procedure - documentation: review and understand the news.txt file and the other upgrade information within this upgrade.txt file. - basis: ensure the existing instance runs the OpenPKG 1.3.1 bootstrap or a CURRENT bootstrap dated in the range 20030925 ... 20040130 inclusive. Later CURRENT bootstraps do not require special attention. Older bootstraps need to be upgraded first. It is safest if the installed packages match the bootstrap release/age. - packages: examine installed packages names and manually check if they still exist in the OpenPKG 2.0 release. $ %{l_prefix}/bin/rpm -qa - applications: examine installed packages for vendor application versions and manually check which vendor version comes with OpenPKG 2.0. Be sure you can handle the new version. $ %{l_prefix}/bin/rpm -qa --queryformat '%{name}-%{VERSION}\n' - options: examine installed packages for options that are in use and manually check if options are still available with or renamed in OpenPKG 2.0 $ %{l_prefix}/bin/rpm -qa --queryformat '%{name} provides: [%{PROVIDES} ]\n' - tag: think about altering the default tag for binaries. - backup: verify the backup of your instance is up to date, complete, readable, integrity checked and stored in a safe location which is accessible after a possibly failed upgrade. If you do not have a proper backup we strongly recommend you rescue at least the whole %{l_prefix}/etc directory. # cd %{l_prefix} && tar cvf /my/safe/place/opkg131etc.tar etc/ - conflict: remove the openpkg-tool package, if currently installed. # %{l_prefix}/bin/rpm -e openpkg-tool - intermediate: upgrade the bootstrap to an intermediate version. This is actually a full featured OpenPKG 2.0 but the Class: header was omitted to allow older bootstraps to rebuild it. $ %{l_prefix}/bin/rpm --rebuild \ ftp://ftp.openpkg.org/release/2.0/SRC/openpkg-1.9.0-2.0.0.src.rpm **** POINT OF NO RETURN **** # %{l_prefix}/bin/rpm -Uvh openpkg-1.9.0-2.0.0.*-*.rpm Starting with a CURRENT bootstrap makes RPM think it performs a downgrade, so --oldpackage is required during an upgrade, see old "RPM downgrade view" issue below. - conversion: rebuild the database, converting it to the new format # %{l_prefix}/bin/openpkg rpm --db-rebuild - upgrade: $ %{l_prefix}/bin/openpkg rpm --rebuild --tag 'mybadge' \ ftp://ftp.openpkg.org/release/2.0/SRC/openpkg-2.0.0-2.0.0.src.rpm # %{l_prefix}/bin/openpkg rpm -Uvh openpkg-2.0.0-2.0.0.*-*.rpm The bootstrap is now upgraded. Continue upgrading the applications one by one. Start with packages that do not require any other packages. Then continue with packages that only require the ones you already upgraded. Repeat this until every package is upgraded. To view dependencies the following query might help. It is a incomplete solution because it can only query install dependencies of installed packages but upgrade also has to take build dependencies into account which might be different and reach out to uninstalled packages. A typical upgrade starts with make, binutils and gcc in that order. $ %{l_prefix}/bin/openpkg rpm -qa --queryformat '%{name} requires:[ %{REQUIRENAME}]\n' \ | sed -e 's;rpmlib(VersionedDependencies) *;;' \ -e 's;OpenPKG *;;' \ -e 's;: openpkg *;: ;' \ -e 's; [^ ]*([^)]*);;g' Be sure you use the new options names when rebuilding. Note that packages where version numbering changed might require a --oldpackage to trick rpm. After perl-openpkg is upgraded old perl-* modules and packages providing perl modules can no longer be build. Check for configuration changes after installing. $ find %{l_prefix}/etc/ -type f | egrep '\.rpm(save|orig|new)' Upgrade from OpenPKG 1.2 to OpenPKG 1.3 ======================================= o important vendor updates: Package | 1.2 | 1.3 =============+=============+============= mysql3 | n/a | 3.23.57 mysql | 3.23.54a | 4.0.14 mysql4 | 4.0.9gamma | n/a -------------+-------------+------------- gcc | 3.2.1 | 3.3 gcc32 | n/a | 3.2.3 -------------+-------------+------------- gd1 | 1.8.4 | removed gd | 2.0.11 | 2.0.15 -------------+-------------+------------- autogen | 5.5 | removed o removed packages: autogen gd1 mysql4 o added packages: aegis atk autotrace awk bogofilter cflow chkrootkit crm114 cscope fontconfig gcc32 getopt glib2 gnuchess gpp gtk2 joe latex2html lcal lesstif lha mtr pango pcal perl-poe sio snort sox txt2html vcg vorbis-libs vorbis-tools xds xmlsec 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. 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 automatic boot and shutdown of all daemons. This does not affect any use of "rc" with a specific package being named. o the rc variable "openpkg_rc_def" is new and it sets the default for enabling or disabling rc sections for a package, as all packages use a "FOO_enable=${openpkg_rc_def}". This allows control of all packages at once. 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 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 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 controlled by the "openpkg_runall" variable. 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 1.3 because their package was removed. -mysql4_enable="yes" -mysql4_pwd_file=@@l_prefix@@/etc/mysql4/my.pwd -mysql4_cnf_file=@@l_prefix@@/etc/mysql4/my.cnf -mysql4_log_prolog="true" -mysql4_log_epilog="true" -mysql4_log_numfiles="10" -mysql4_log_minsize="1M" -mysql4_log_complevel="9" -mysql4_pid_file=@@l_prefix@@/var/mysql4/mysqld.pid -mysql4_log_err=@@l_prefix@@/var/mysql4/mysqld.err -mysql4_log_common=@@l_prefix@@/var/mysql4/common.log -mysql4_log_update=@@l_prefix@@/var/mysql4/update.log o No new rc.conf variables were introduced by the new packages being 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 1.2 (-), added to OpenPKG 1.3 (+), changed (both - and +) or which remain untouched (=). -amd_enable="yes" +amd_enable="$openpkg_rc_def" =amd_log_complevel="9" =amd_log_epilog="true" =amd_log_minsize="1M" =amd_log_numfiles="10" =amd_log_prolog="true" -apache_enable="yes" +apache_enable="$openpkg_rc_def" -apache_log_rotprolog="true" -apache_log_rotepilog="true" -apache_log_rotsteps="10" -apache_log_rotminsize="10M" -apache_log_rotcomplevel="9" +apache_log_prolog="true" +apache_log_epilog="true" +apache_log_numfiles="10" +apache_log_minsize="1M" +apache_log_complevel="9" -apache_err_rotprolog="true" -apache_err_rotepilog="true" -apache_err_rotsteps="10" -apache_err_rotminsize="1M" -apache_err_rotcomplevel="9" +apache_err_prolog="true" +apache_err_epilog="true" +apache_err_numfiles="10" +apache_err_minsize="1M" +apache_err_complevel="9" =apache_err_files="@@l_prefix@@/var/apache/log/error.log" =apache_log_files="@@l_prefix@@/var/apache/log/access.log" -bind_enable="yes" -bind_log_numfiles="5" -bind_log_minsize="512K" +bind_enable="$openpkg_rc_def" +bind_flags="" +bind_log_prolog="true" +bind_log_epilog="true" +bind_log_numfiles="10" +bind_log_minsize="1M" =bind_log_complevel="9" -cvs_pserverd_enable="no" -cvs_pserverd_gflags="" -cvs_pserverd_lflags="" -cvs_pserverd_listen="127.0.0.1:2401" +cvs_enable="$openpkg_rc_def" +cvs_gflags="" +cvs_lflags="" +cvs_listen="127.0.0.1:2401" +cvs_log_prolog="true" +cvs_log_epilog="true" +cvs_log_numfiles="10" +cvs_log_minsize="1M" +cvs_log_complevel="9" -cvsd_enable="yes" +cvsd_enable="$openpkg_rc_def" +cvsd_log_prolog="true" +cvsd_log_epilog="true" +cvsd_log_numfiles="10" +cvsd_log_minsize="1M" +cvsd_log_complevel="9" -dhcpd_enable="yes" +dhcpd_enable="$openpkg_rc_def" +dhcpd_flags="-q" +dhcpd_if="" +dhcpd_port="67" +dhcpd_log_prolog="true" +dhcpd_log_epilog="true" +dhcpd_log_numfiles="10" +dhcpd_log_minsize="1M" +dhcpd_log_complevel="9" +findutils_enable="$openpkg_rc_def" -inn_enable="yes" -inn_nntpsend_enable="no" +inn_enable="$openpkg_rc_def" +inn_nntpsend_enable="$openpkg_rc_def" -ircd_enable="yes" +ircd_enable="$openpkg_rc_def" +ircd_log_prolog="true" +ircd_log_epilog="true" +ircd_log_numfiles="10" +ircd_log_minsize="1M" +ircd_log_complevel="9" +less_enable="$openpkg_rc_def" -lmtp2nntp_enable="yes" +lmtp2nntp_enable="$openpkg_rc_def" =lmtp2nntp_log_complevel="9" =lmtp2nntp_log_epilog="true" =lmtp2nntp_log_level="info" =lmtp2nntp_log_minsize="1M" =lmtp2nntp_log_numfiles="10" =lmtp2nntp_log_prolog="true" =lmtp2nntp_nicelevel="20" -mico_enable="no" +mico_enable="$openpkg_rc_def" -mico_nsd_args="-ORBGIOPVersion 1.2 -ORBIIOPVersion 1.2 -ORBIIOPAddr inet:`uname -n`:8912" +mico_nsd_args="-ORBGIOPVersion 1.2 -ORBIIOPVersion 1.2 -ORBIIOPAddr inet:`uname -n`:8914" =mico_micod="no" =mico_micod_args="-ORBGIOPVersion 1.2 -ORBIIOPVersion 1.2 -ORBIIOPAddr inet:`uname -n`:8912" =mico_nsd="no" -mysql_enable="yes" +mysql_enable="$openpkg_rc_def" =mysql_cnf_file=@@l_prefix@@/etc/mysql/my.cnf =mysql_log_complevel="9" =mysql_log_epilog="true" =mysql_log_minsize="1M" =mysql_log_numfiles="10" =mysql_log_prolog="true" =mysql_pwd_file=@@l_prefix@@/etc/mysql/my.pwd -ntp_enable="yes" +ntp_enable="$openpkg_rc_def" +ntp_ostart="yes" +ntp_hourly="no" =ntp_daemon="yes" =ntp_log_complevel="9" =ntp_log_epilog="true" =ntp_log_minsize="1M" =ntp_log_numfiles="10" =ntp_log_prolog="true" -openldap_enable="yes" +openldap_enable="$openpkg_rc_def" +openldap_flags="" +openldap_url="ldap://127.0.0.1:389" +openldap_log_prolog="true" +openldap_log_epilog="true" +openldap_log_numfiles="10" +openldap_log_minsize="1M" +openldap_log_complevel="9" -openpkg_runall="yes" +openpkg_rc_def="yes" +openpkg_rc_all="$openpkg_rc_def" +openpkg_enable="$openpkg_rc_def" =openpkg_envprio="high" -openssh_enable="yes" +openssh_enable="$openpkg_rc_def" =openssh_log_complevel="9" =openssh_log_epilog="true" =openssh_log_minsize="1M" =openssh_log_numfiles="10" =openssh_log_prolog="true" -pam_enable="yes" +pam_enable="$openpkg_rc_def" =pam_cfgloc='@@pam_cfgloc@@' =pam_incdir='@@pam_incdir@@' =pam_libdir='@@pam_libdir@@' =pam_modpfx='@@pam_modpfx@@' -pb4sd_enable="yes" +pb4sd_enable="$openpkg_rc_def" -pb4sd_pidfile="@@l_prefix@@/var/pb4sd/pb4sd.pid" =pb4sd_dbfile="@@l_prefix@@/var/pb4sd/pb4sd.db" =pb4sd_exclude="127.0.0.0/8" =pb4sd_grace="3600" =pb4sd_log_complevel="9" =pb4sd_log_epilog="true" =pb4sd_log_minsize="1M" =pb4sd_log_numfiles="10" =pb4sd_log_prolog="true" =pb4sd_logfile="@@l_prefix@@/var/pb4sd/pb4sd.log" -portfwd_enable="yes" +portfwd_enable="$openpkg_rc_def" +portfwd_log_prolog="true" +portfwd_log_epilog="true" +portfwd_log_numfiles="10" +portfwd_log_minsize="1M" +portfwd_log_complevel="9" =portfwd_flags="" -portsentry_enable="yes" +portsentry_enable="$openpkg_rc_def" +portsentry_log_prolog="true" +portsentry_log_epilog="true" +portsentry_log_numfiles="10" +portsentry_log_minsize="1M" +portsentry_log_complevel="9" -postfix_enable="yes" +postfix_enable="$openpkg_rc_def" -mta_name="postfix" -mta_aliases_file="@@l_prefix@@/etc/postfix/aliases" -mta_aliases_update="cd @@l_prefix@@/etc/postfix && @@l_prefix@@/sbin/postalias aliases" +MTA_name="postfix" +MTA_aliases_file="@@l_prefix@@/etc/postfix/aliases" +MTA_aliases_update="cd @@l_prefix@@/etc/postfix && @@l_prefix@@/sbin/postalias aliases" =postfix_log_complevel="9" =postfix_log_epilog="true" =postfix_log_minsize="1M" =postfix_log_numfiles="10" =postfix_log_prolog="true" =postfix_sum_flags="" -postgresql_enable="yes" +postgresql_enable="$openpkg_rc_def" -postgresql_socket_inet="localhost" +postgresql_socket_inet="127.0.0.1" -postgresql_log_file="@@l_prefix@@/var/postgresql/run/postmaster.log" =postgresql_datadir="@@l_prefix@@/var/postgresql/db" =postgresql_flags="" =postgresql_log_complevel="9" =postgresql_log_epilog="true" =postgresql_log_minsize="1M" =postgresql_log_numfiles="10" =postgresql_log_prolog="true" =postgresql_shut_mode="smart" =postgresql_socket_unix="@@l_prefix@@/var/postgresql/run/" -proftpd_enable="yes" +proftpd_enable="$openpkg_rc_def" +proftpd_acc_file="@@l_prefix@@/var/proftpd/proftpd.access.log" +proftpd_acc_prolog="true" +proftpd_acc_epilog="true" +proftpd_acc_numfiles="10" +proftpd_acc_minsize="1M" +proftpd_acc_complevel="9" +proftpd_auth_file="@@l_prefix@@/var/proftpd/proftpd.auth.log" +proftpd_auth_prolog="true" +proftpd_auth_epilog="true" +proftpd_auth_numfiles="10" +proftpd_auth_minsize="1M" +proftpd_auth_complevel="9" +proftpd_sys_file="@@l_prefix@@/var/proftpd/proftpd.system.log" +proftpd_sys_prolog="true" +proftpd_sys_epilog="true" +proftpd_sys_numfiles="10" +proftpd_sys_minsize="1M" +proftpd_sys_complevel="9" +proftpd_xfer_file="@@l_prefix@@/var/proftpd/proftpd.xfer.log" +proftpd_xfer_prolog="true" +proftpd_xfer_epilog="true" +proftpd_xfer_numfiles="10" +proftpd_xfer_minsize="1M" +proftpd_xfer_complevel="9" -pureftpd_enable="yes" +pureftpd_enable="$openpkg_rc_def" +pureftpd_flags="" +pureftpd_bind="127.0.0.1" +pureftpd_port="21" +pureftpd_log_prolog="true" +pureftpd_log_epilog="true" +pureftpd_log_numfiles="10" +pureftpd_log_minsize="1M" +pureftpd_log_complevel="9" -qpopper_enable="yes" +qpopper_enable="$openpkg_rc_def" -pop_type="qpopper" -pop_logfile="@@l_prefix@@/var/qpopper/qpopper.log" +POP_type="qpopper" +POP_logfile="@@l_prefix@@/var/qpopper/qpopper.log" =qpopper_bind="127.0.0.1:110" =qpopper_log_complevel="9" =qpopper_log_epilog="true" =qpopper_log_minsize="1M" =qpopper_log_numfiles="10" =qpopper_log_prolog="true" -radius_enable="yes" +radius_enable="$openpkg_rc_def" -rsync_enable="yes" +rsync_enable="$openpkg_rc_def" +rsync_daemon="yes" +rsync_bind="127.0.0.1" +rsync_port="873" -rsync_log_numfiles="5" -rsync_log_minsize="512K" +rsync_log_prolog="true" +rsync_log_epilog="true" +rsync_log_numfiles="10" +rsync_log_minsize="1M" =rsync_flags="" =rsync_log_complevel="9" =rsync_nicelevel="10" -samba_enable="yes" +samba_enable="$openpkg_rc_def" +samba_log_prolog="true" +samba_log_epilog="true" +samba_log_numfiles="10" +samba_log_minsize="1M" +samba_log_complevel="9" -samhain_enable="yes" +samhain_enable="$openpkg_rc_def" +samhain_log_prolog="true" +samhain_log_epilog="true" +samhain_log_numfiles="10" +samhain_log_minsize="1M" +samhain_log_complevel="9" -sasl_enable="yes" -sasl_authmech="@@authmech@@" -sasl_threads="5" +sasl_enable="$openpkg_rc_def" +sasl_authmech="@@l_authmech@@" +sasl_threads="2" +sasl_log_prolog="true" +sasl_log_epilog="true" +sasl_log_numfiles="10" +sasl_log_minsize="1M" +sasl_log_complevel="9" -sendmail_enable="yes" +sendmail_enable="$openpkg_rc_def" -mta_name="sendmail" -mta_aliases_file="@@l_prefix@@/etc/sendmail/t.aliases" -mta_aliases_update="cd @@l_prefix@@/etc/sendmail && make t.aliases.db" +MTA_name="sendmail" +MTA_aliases_file="@@l_prefix@@/etc/sendmail/t.aliases" +MTA_aliases_update="cd @@l_prefix@@/etc/sendmail && make t.aliases.db" -sendmail_rotate_prolog="" -sendmail_rotate_epilog="" -sendmail_rotate_numfiles="10" -sendmail_rotate_minsize="1M" -sendmail_rotate_complevel="9" +sendmail_flags_msp="-Ac -q60s" +sendmail_wait_timeout="60" +sendmail_log_prolog="true" +sendmail_log_epilog="true" +sendmail_log_numfiles="10" +sendmail_log_minsize="1M" +sendmail_log_complevel="9" =sendmail_flags="" =sendmail_flags_in="-bd" =sendmail_flags_out="-q60s" -smtpfeed_enable="no" +smtpfeed_enable="$openpkg_rc_def" -smtpfeed_bind_local="127.0.0.1:2525" -smtpfeed_bind_remote="0.0.0.0" +smtpfeed_bind="127.0.0.1" +smtpfeed_port="2525" +smtpfeed_source_addr="" +smtpfeed_source_port="" =smtpfeed_flags="-u -V" =smtpfeed_hostname="localhost" =smtpfeed_log_complevel="9" =smtpfeed_log_epilog="true" =smtpfeed_log_minsize="1M" =smtpfeed_log_numfiles="10" =smtpfeed_log_prolog="true" =smtpfeed_maxrcpt="100" =smtpfeed_maxsize="4194304" =smtpfeed_timeout_connect="1m" =smtpfeed_timeout_greet="2m" =smtpfeed_timeout_rset="2m" =spamassassin_enable="$openpkg_rc_def" -squid_enable="yes" +squid_enable="$openpkg_rc_def" +squid_log_prolog="true" +squid_log_epilog="true" +squid_log_numfiles="10" +squid_log_minsize="1M" +squid_log_complevel="9" -sysmon_enable="yes" +sysmon_enable="$openpkg_rc_def" +sysmon_log_prolog="true" +sysmon_log_epilog="true" +sysmon_log_numfiles="10" +sysmon_log_minsize="1M" +sysmon_log_complevel="9" +sysmon_stop_timeout="60" -teapop_enable="yes" +teapop_enable="$openpkg_rc_def" -pop_type="teapop" -pop_logfile="@@l_prefix@@/var/teapop/teapop.log" +POP_type="teapop" +POP_logfile="@@l_prefix@@/var/teapop/teapop.log" =teapop_log_complevel="9" =teapop_log_epilog="true" =teapop_log_minsize="1M" =teapop_log_numfiles="10" =teapop_log_prolog="true" -tftp_enable="yes" -tftp_listen="" +tftp_enable="$openpkg_rc_def" +tftp_listen="127.0.0.1:69" +tftp_log_prolog="true" +tftp_log_epilog="true" +tftp_log_numfiles="10" +tftp_log_minsize="1M" +tftp_log_complevel="9" =tftp_flags="" =tftp_rootdir="@@l_prefix@@/pub" -uucp_enable="yes" +uucp_enable="$openpkg_rc_def" +uucp_flags="-l" +uucp_bind="127.0.0.1" +uucp_port="540" +uucp_log_prolog="true" +uucp_log_epilog="true" +uucp_log_numfiles="10" +uucp_log_minsize="1M" +uucp_log_complevel="9" +vim_enable="$openpkg_rc_def" =x11_bindir="@@x11_bindir@@" =x11_incdir="@@x11_incdir@@" =x11_libdir="@@x11_libdir@@" -zebra_enable="yes" +zebra_enable="$openpkg_rc_def" +zebra_protocols="rip ospf bgp" +zebra_flags="" +zebra_bind="127.0.0.1" +zebra_port="2601" +zebra_rip_flags="" +zebra_rip_bind="${zebra_bind}" +zebra_rip_port="2602" +zebra_ospf_flags="" +zebra_ospf_bind="${zebra_bind}" +zebra_ospf_port="2604" +zebra_bgp_flags="" +zebra_bgp_bind="${zebra_bind}" +zebra_bgp_port="2605" +zebra_log_prolog="true" +zebra_log_epilog="true" +zebra_log_numfiles="10" +zebra_log_minsize="1M" +zebra_log_complevel="9" o packages containing services to be run in the background now consistently provide "start", "stop" and "restart" sections. Some also provide a "reload" section. o A new section "status" was created which allows for querying 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 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 and running. 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 3rd) upgrade the package (-Uvh) 4th) handle and remove all .rpm(save|old|orig) files 5th) start the service (%{l_prefix}/etc/rc service start) 6th) [ erase a package (-e) ] The first step is not different from previous releases of OpenPKG. The second step might be anything from nothing and restart from scratch, copying, archiving or ignoring it completely because you have a configuration management system which builds the configuration from a source external to OpenPKG. 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 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 restart will keep stopped services stopped and running services will experience a stop/start combination. We found two categories of services. Regarding the restart issue, a simple service can continue to run during the upgrade and only requires a "rc service restart" after the upgrade (i.e. openssh). This works for any service that only reads it's configuration during startup. The majority of services falls into this category. Some complex ones read their configuration while they are up and running (i.e. postfix) based on new connections, timing, external signal, timestamp monitoring or whatever. Or they require more complex upgrade activity like user data conversion (i.e. postgresql). For the complex ones (find comment "before upgrade, save status and stop service" of the %pre section in the spec) the running state is saved before the upgrade, the service is stopped using "rc service stop" and after the upgrade 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 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 executed by cron, i.e. log file rotation in %daily scriptlet) and starting or restarting is effectively inhibited. For all other sections, including %status and %env, this situation is considered a warning, a message is printed to stderr (...cron...) but execution will continue. This behaviour is already true for the final %post scriptlet in the third step discussed above. Simple services just won't restart and the old one will continue to run (rc %restart is suppressed) until stopped somehow. Complex services have been shut down in the %pre scriptlet (rc %stop) and might not come up again after the upgrade (rc %start is suppressed). This altogether leads to the point that after an upgrade, the new service might not be startable. You have to move the .rpm(save|old|orig) out of "rc" sight by renaming, moving or removing them somehow. This could be done manually, it could also be done automatically by a 3rd party configuration management. As a sidenote please understand the default configuration of all CORE and BASE packages (except ntp and amd) were altered to force the daemon to listen on 127.0.0.1. This reduces interference with other (system, different OpenPKG instance) similar services. It also ensures that the service is not exposed to the outer world without your explicit configuration, this enhances security (and increases travel expenses if you forget to tweak your sshd_config!). Last but not least, it means that services which do awkward (i.e. apache showing default index page) or deadly (i.e. postfix rejecting incoming mails) things in the default config won't do it without making you fully responsible :-) The fifth step is only necessary if the running state should forcibly change after an upgrade or the automatic run state recovery that executed in the %post scriptlet before the configuration management cleaned out things failed. After the blocking files have been removed, further "rc start" or "rc restart" actions will succeed. Note that simple services will have the old service up and running and require a %restart (= %stop %start) while complex services were already stopped and require a %start. Note that %restart will not do anything if the service is not already running. Also note that %start will not do anything if the service is already running. If you're in doubt, execute "rc service restart start" after configuration management took place. Just for completeness, the sixth step would be a package erase. All CORE and BASE packages were tuned to shut down the service (find comment "before erase, stop service" in %preun section of the spec), erase log (including statistics and history) and run (pidfiles, UNIX domain socket files) files without notice. If you want to keep them, refrain from erasing or save that data first. User data like databases will not be removed, of course (trusting this statement blindly and omitting backups might result in an interesting experience of life :-) o Squid now runs under rusr instead of musr. You've to chown the /var/squid/cache directory to rusr:rgrp. o More bullets FIXME - sharutils requirement (SuSE) - removal of /var files including logs on erase - restart of application on startup - behaviour of rc output when executing a %section and the -o option - default daemons (including openssh) to listen on localhost (no wildcards, except amd/ntp) - fsl optional, defaults to yes; append=1 vs. trunc=0; jitter=1 - linters (i.e. use rclint for opServiceEnabled vs. rcService) - %{l_value} - inhibit rc ... start if .rpmsave found ... openpkg:rc:WARNING: package "squid" has unresolved configuration file conflicts openpkg:rc:WARNING: indicated by "*.rpm(new|orig|save)" files in "/cw/etc/squid" Upgrade from OpenPKG 1.1 to OpenPKG 1.2 ======================================= o coreutils GNU merged their fileutils, shellutils and textutils projects into the new coreutils. Hence the three OpenPKG packages fileutils, shellutils and textutils were removed from OpenPKG-CURRENT and a new coreutils package was created which replaces the three obsoleted ones now. Upgrade from OpenPKG 1.0 to OpenPKG 1.1 ======================================= o libiconv When upgrading the "libiconv" package you first have to deinstall ("rpm -e libiconv") the old version before building ("rpm --rebuild") and installing ("rpm -Uvh") the new version. This is due to the fact that libiconv would see the old version's include files and hence break to build. o Berkeley-DB and OpenLDAP The "db" package is now Berkeley-DB 4.0 while the Berkeley-DB 3.3 is now named "db3". When upgrading "openldap" (or similar packages which require "db") you first have to upgrade the "db" package, too. If other packages (like "inn") require DB 3 you also have to additionally install "db3". o Additional user accounts OpenPKG 1.1 adds additional user accounts to the system. The new UIDs are not used by the bootstrap itself and can be changed by manually configuring the system files immediately after the upgrade. Do not modify them after any dependent packages were installed (i.e. postfix and sendmail) as these packages might compile UIDs into the binary. o Removed Packages OpenPKG 1.1 does not include autogen, guile, imapd and sfio. They have been put into EVAL or JUNK classes and are only available as CURRENT packages which can be downloaded as source RPMs from ftp://ftp.openpkg.org/CURRENT/SRC/. o Inconsistent rc.conf variables in rsync Previously the rsync package inconsistently used rc.conf variables with prefix "rsyncd_". This was now corrected to be "rsync_". The entries in rc.conf have to be corrected manually. o BIND8 vs BIND9 In OpenPKG 1.1 the "bind" package is based on BIND9 where OpenPKG 1.0 used BIND8. The old package was renamed to "bind8" to support installations which depend on BIND8. Because the package name changed, RPM treats it as two different packages. The configuration of the old package must be backed up manually, then the old package needs to be removed. Finally the new "bind8" package must be installed and configuration recovered manually. o PAM In OpenPKG 1.0 some daemon packages by default had PAM support enabled. Unfortunately PAM makes trouble in a cross-platform approach, hence OpenPKG 1.1 has PAM support disabled in all packages by default. Instead PAM support can be consistently enabled there through a --define "with_pam yes" during build-time. This now requires the "pam" glue package to be installed first. This "pam" package now takes over the task of reconfiguring the /etc/pam.d/ or /etc/pam.conf in a consistent way. The following table compares PAM support between this and the previous OpenPKG release. OpenPKG 1.0 OpenPKG 1.1 PAM support in OpenPKG 1.1 -------------------------------------------------------------------- apache apache %with_mod_auth_pam imapd n/a package removed openldap openldap no PAM support openssh openssh %with_pam proftpd proftpd %with_pam pureftpd pureftpd %with_pam qpopper qpopper %with_pam samba samba %with_pam n/a sasl %with_pam; new package sudo sudo %with_pam o Bootstrapping and C Compiler For machines which do not have any C compiler at all (Solaris!), you usually have to install a gcc via binary somewhere. If it is outside the OpenPKG hierarchy, the sane build environment prevents OpenPKG from finding and using it. To tell OpenPKG about this "cc" you have to add an ~/.rpmmacros with "%with_cc /path/to/this/bootstrap/cc". o Shared Libraries OpenPKG still has the policy of not using shared libraries for cross-platform reasons. Nevertheless by accident some OpenPKG 1.0 packages (e.g. "mysql") included shared library versions. If you had installed packages (e.g. "apache+mod_php") which linked against the MySQL shared libraries, those packages are broken until also upgraded and rebuilt. To avoid such temporary brokeness, this means you should make sure that an all packages at once are upgraded from OpenPKG 1.0 to 1.1 if possible. Upgrade from OpenPKG-CURRENT to OpenPKG 1.1 =========================================== o RPM downgrade view: Please understand the difference between a real up-/downgrade compared to what RPM thinks is a up-/downgrade. 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 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. o binutils/gcc/openpkg: If binutils and gcc-3.2 were installed previously, binutils, gcc and openpkg must be upgraded in exacly that order. Due to a problem with binutils before 200208261229 FreeBSD users will receive static ELF binaries with the wrong brand. The loader will reject them with error 'ELF binary type "0" not known'. Unfortunately, the /cw/lib/openpkg/rpm executable called by the /cw/bin/rpm wrapper is such a binary. If you receive this error the last chance to recover is to brand the binary manually, i.e. using $ brandelf -t "FreeBSD" /cw/lib/openpkg/rpm 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 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 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 gcc-3.2-20020815 = gcc-3.2-1.1.0 Upgrade from OpenPKG 0.9 to OpenPKG 1.0 ======================================= No known issues. Upgrade from rpm-4.0-N to OpenPKG 0.9 ===================================== o Upgrading Bootstrap Package: Until July 2001 the OpenPKG (http://www.openpkg.org/) bootstrap package was named "rpm-4.0-N". Because over the time it mutated into something which is actually a lot more than just RPM, it was renamed to "openpkg-0.9-N" recently. For safe upgrading in the future, it is _VERY_ important that all already existing OpenPKG installations are _NOW_ upgraded to the new bootstrap package. For the experts: it has to be done before we rename/add/delete files in forthcoming openpkg-0.9-X versions, because otherwise a complete reinstall would be required later or the database would no longer be in sync with the installed files if you upgrade too late. To determine whether an OpenPKG hierarchy has to be upgraded, run the following command: # 0. determine current state $ rpm -qa | egrep '(rpm|openpkg)' If the output is "rpm-4.0-X" upgrading is required. If the output is "openpkg-0.9-X" upgrading was already done (perhaps by someone else) and so you do _NOT_ have to upgrade immediately. If upgrading is required, enter as soon as possible the following commands as "root" exactly as they are written down here and in exactly this order for every OpenPKG filesystem hierarchy (replace /cw with the path to your particular OpenPKG hierarchy): # 1. enter the OpenPKG filesystem hierarchy (for relative paths below) $ cd /cw # 2. rebuild the OpenPKG bootstrap package for this hierarchy $ bin/rpm --rebuild http://www.openpkg.org/pkg/openpkg-0.9-8.src.rpm # 3. remove the old bootstrap name from RPM database $ bin/rpm -e --justdb --nodeps rpm # 4. install the new bootstrap [expect 2 warnings] $ bin/rpm -i --noscripts --nodeps --force RPM/PKG/openpkg-0.9-8.*.rpm # 5. rebuild the RPM database $ bin/rpm --rebuilddb # 6. cleanup after upgrade $ rm -f etc/rpm/*.rpmorig For more details or help in case of problems, feel free to contact Ralf. @ 1.45 log @note change to openpkg-tools package @ text @d5 1 a5 1 o $Revision: 1.44 $. The most recent update of this file can be d38 12 @ 1.44 log @note updated companion >= openpkg-1.9.1-2.0.1 are available @ text @d5 1 a5 1 o $Revision: 1.43 $. The most recent update of this file can be d268 1 a268 1 upgrading. After the upgrade a new openpkg-tool package can be d276 1 a276 1 after the CURRENT version of openpkg-tool has been installed. d286 1 a286 1 - openpkg-tool available as CURRENT package @ 1.43 log @fix typos, grammar; minor fixes; cosmetics @ text @d5 1 a5 1 o $Revision: 1.42 $. The most recent update of this file can be d149 2 @ 1.42 log @log ulimit and openssh pitfall @ text @d5 1 a5 1 o $Revision: 1.41 $. The most recent update of this file can be d19 1 a19 1 in an incompatible way. Any possible damage could have been done to d54 1 a54 1 $ /cw/bin/rpm --db-rebuild d69 2 a70 1 macro. For no limits set ~/.rpmmacros of the building user to %nil. d72 1 a72 1 $ echo "%l_build_ulim %nil" >>$PREFIX/.rpmmacros d84 1 a84 1 $ $PREFIX/etc/rc openssh start status d102 1 a102 1 o new ndbm behaviour d161 1 a161 1 point undistinguishable from a fresh install. d177 1 a177 1 boostrap during upgrade you probably tried to skip the intermediate d301 1 a301 1 made release engineering unnessessary hard. Adjusting the version d327 1 a327 1 whenenver one of the vendor version changes. d334 1 a334 1 Some of these changes make RPM think it performes a downgrade, so d372 1 a372 1 attention. Older boostraps need to be upgraded first. It is safest d424 1 a424 1 Starting with a CURRENT bootstrap makes RPM think it performes a @ 1.41 log @once again explain CURRENT to RELEASE "downgrade" issue @ text @d5 1 a5 1 o $Revision: 1.40 $. The most recent update of this file can be d62 22 @ 1.40 log @note "man index" will only work if openpkg-tool has been reinstalled (feedback from Johann Gutauer) @ text @d5 1 a5 1 o $Revision: 1.39 $. The most recent update of this file can be d311 3 a313 2 Some these changes might make RPM think it performes a downgrade, so --oldpackage might be required during an upgrade. Example: d400 4 a403 1 CURRENT users add --oldpackage @ 1.39 log @add "packages with OpenPKG number appended" note (feedback from Cyrus Hamidi) @ text @d5 1 a5 1 o $Revision: 1.38 $. The most recent update of this file can be d250 2 a251 1 However, access to the manual page(s) changed @ 1.38 log @improve dependency query and document its limitations (feedback from Johann Gutauer) @ text @d5 1 a5 1 o $Revision: 1.37 $. The most recent update of this file can be d316 20 @ 1.37 log @mention build host issue in "upgrade procedure with intermediate step" (feedback from Christian Reiber) @ text @d5 1 a5 1 o $Revision: 1.36 $. The most recent update of this file can be d394 7 a400 1 View dependencies: d402 4 a405 1 | sed -e 's;[Oo]pen[Pp][Kk][Gg] *;;g' -e 's; [^ ]*([^)]*);;g' @ 1.36 log @typos and whitespace removal @ text @d5 1 a5 1 o $Revision: 1.35 $. The most recent update of this file can be d116 32 a147 18 While RPM silently ignores unknown sections, the introduction of 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 package 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 one of the following two steps: - possibility 1: we provide an intermediate openpkg-1.9.0-2.0.0.src.rpm (intentionally no src.sh available) package which can be rebuild and installed using a 1.x bootstrap. This intermediate package is only supported to fulfill the upgrade operation. - possibility 2: install 2.0.0 source RPM, filter the offending "Class:" header out from the spec and build binary. Or get ingredients from 2.0.0 source RPM using rpm2cpio, filter the offending header out from the spec and build binary. @ 1.35 log @relax example complexity using a constant tag @ text @d5 1 a5 1 o $Revision: 1.34 $. The most recent update of this file can be d31 1 a31 1 replacements and usually require little or no brain work. They d34 2 a35 2 security compatiblity as we only support the latest release and it's immediate predecessor. So don't fall behind by running outdated d45 1 a45 1 d51 1 a51 1 d83 1 a83 1 compatiblity provided by gdbm. d111 2 a112 2 suPHP can be use on legacy setups. d155 1 a155 1 compatiblity to existing %{l_location}. d165 1 a165 1 d212 1 a212 1 1 1 1 OpenPKG 2.0 with /bin/rpm compatiblity wrapper d290 1 a290 1 d389 1 a389 1 d433 1 a433 1 d920 1 a920 1 d1065 1 a1065 1 @ 1.34 log @remove wrong info; rc system will only choke if a OpenPKG <= 1.2 bootstrap should run a OpenPKG >= 1.3 rc script (due to opServiceEnabled migration to opService) @ text @d5 1 a5 1 o $Revision: 1.33 $. The most recent update of this file can be d371 1 a371 1 $ %{l_prefix}/bin/openpkg rpm --rebuild --tag '@@' \ @ 1.33 log @bugfixes @ text @d5 1 a5 1 o $Revision: 1.32 $. The most recent update of this file can be d356 1 a356 2 allow older bootstraps to rebuild it. The rc system will choke if you have outdated pre-OpenPKG 1.3 packages installed! FIXME: WHY? @ 1.32 log @remove outdated/cleared FIXMEs @ text @d5 1 a5 1 o $Revision: 1.31 $. The most recent update of this file can be d119 14 a132 14 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. - we provide an intermediate openpkg-1.9.0-2.0.0.src.rpm (intentionally no src.sh available) package which can be rebuild and installed using a 1.x bootstrap. This intermediate package is only supported to fulfill the upgrade operation. - 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 d184 2 a185 2 $ /13/bin/rpm -qi openpkg $ /20/bin/openpkg rpm -qi openpkg d233 2 a234 2 $ /13/bin/openpkg build -Ua $ /20/bin/openpkg build -Ua d313 2 a314 2 attention. Older boostraps need to be upgraded first. Also be sure the installed packages match the bootstrap release/age. d354 1 a354 1 upgrade the bootstrap to an intermediate version. This is acutally d357 1 a357 1 you have outdated pre-OpenPKG 1.3 packages installed! d1029 1 a1030 1 - check anything listed here must be moved to NEWS or vice versa @ 1.31 log @intermediate starts with 1.9.0 @ text @d5 1 a5 1 o $Revision: 1.30 $. The most recent update of this file can be d239 2 a240 2 20$ openpkg man index #FIXME openpkg man not implemented as of 20040217 20$ openpkg man build #FIXME openpkg man not implemented as of 20040217 d313 2 a314 3 attention. Older boostraps need to be upgraded first. [FIXME what about sooner boostraps, 1.3.0 and 1.2.x?] Also be sure the installed packages match the bootstrap release/age. @ 1.30 log @consistently replace version syntax vN.M by N.M @ text @d5 1 a5 1 o $Revision: 1.29 $. The most recent update of this file can be d124 1 a124 1 - we provide an intermediate openpkg-1.9.9-2.0.0.src.rpm d361 1 a361 1 ftp://ftp.openpkg.org/release/2.0/SRC/openpkg-1.9.9-2.0.0.src.rpm d365 1 a365 1 # %{l_prefix}/bin/rpm -Uvh openpkg-1.9.9-2.0.0.*-*.rpm @ 1.29 log @push down FIXMEs; update upgrade recommendation after live-test @ text @d5 1 a5 1 o $Revision: 1.28 $. The most recent update of this file can be d65 1 a65 1 OpenPKG v1.3 OpenPKG 2.0 d91 1 a91 1 implementation. Upgrades from OpenPKG v1.3 will have used the d99 1 a99 1 OpenPKG v2.0 application which reads gdbm::with_ndbm file format. d151 1 a151 1 In OpenPKG v2.0, the location id is replaced by a user configurable d187 1 a187 1 OpenPKG v2.0 provides a wrapper for "rpm" and "rpm2cpio" to be found d191 1 a191 1 to STDERR. Please note that OpenPKG v2.1 will discontinue support d208 1 a208 1 0 1 1 OpenPKG v2.1 (and later) d212 1 a212 1 1 1 1 OpenPKG v2.0 with /bin/rpm compatiblity wrapper d254 1 a254 1 never used snapshots and OpenPKG v2.0 makes no attempt to use a d264 1 a264 1 was a manual and error prone task. In fact OpenPKG v1.3 had such d333 1 a333 1 OpenPKG v2.0 d400 1 a400 1 Package | v1.2 | v1.3 d445 2 a446 2 OpenPKG v1.2 FOO_enable="yes" OpenPKG v1.3 FOO_enable="$openpkg_rc_def" d449 1 a449 1 OpenPKG v1.3 because their package was removed. d465 1 a465 1 added to OpenPKG v1.3. d469 1 a469 1 v1.2 (-), added to OpenPKG v1.3 (+), changed (both - and +) or which d933 1 a933 1 o The OpenPKG v1.3 way of upgrading a package d952 1 a952 1 exactly like previous releases of OpenPKG. Now for the news in v1.3: d973 1 a973 1 OpenPKG v1.3, "rc" checks if it finds any .rpm(save|old|orig) files d1181 2 a1182 2 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 d1184 1 a1184 1 v1.1.0 is a real downgrade. @ 1.28 log @recommended manual upgrade procedure @ text @d5 1 a5 1 o $Revision: 1.27 $. The most recent update of this file can be d165 11 d242 1 a242 1 o packages dropped from release (FIXME check for completeness) d244 4 a247 1 - openpkg-tool is available as CURRENT package d350 1 a350 1 remove the openpkg-tool package, if currently in use. a353 1 d365 2 a366 1 # %{l_prefix}/bin/rpm -Uvh openpkg-1.9.9-2.0.0-*.rpm d373 1 a373 1 $ %{l_prefix}/bin/openpkg rpm --rebuild --tag='@@' \ d375 1 a375 1 # %{l_prefix}/bin/openpkg rpm -Uvh openpkg-2.0.0-2.0.0-*.rpm d377 2 a378 2 The bootstrap is now upgraded. Now upgrade the applications step by step. Start with packages that do not require other packages. d380 1 a380 1 upgraded. Do until every package is upgraded. d388 3 a390 1 --oldpackage to trick rpm. d1029 2 a1030 3 o FIXME - mention sharutils requirement (SuSE) - mention solaris requirements (feedback from Ingo) @ 1.27 log @better check for rpm executable file @ text @d5 1 a5 1 o $Revision: 1.26 $. The most recent update of this file can be d124 4 a127 4 - 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. d135 8 d288 87 d376 3 @ 1.26 log @--tag infos @ text @d5 1 a5 1 o $Revision: 1.25 $. The most recent update of this file can be d184 1 a184 1 | | /libexec/openpkg @ 1.25 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 @ text @d5 1 a5 1 o $Revision: 1.24 $. The most recent update of this file can be d137 20 a156 3 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. @ 1.24 log @clear item; log how the version=release problem was solved @ text @d5 1 a5 1 o $Revision: 1.23 $. The most recent update of this file can be d41 1 a41 1 o RPM 4.0.2 to 4.2.1: d43 4 a46 1 you can't go back and require a --db-rebuild afterwards! d48 1 a48 2 o if RPM hangs during installation of a package or you get a "Resource temporarily unavailable", it's time for --db-rebuild d50 2 a62 24 More background information from openpkg.spec log (revision 1.219): Completely revamp the RPM database fiddling: Introduce new /lib/openpkg/rpmdb utility for administrating the RPM database on the lower level and hook it into the /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) d79 1 a79 1 o ndbm d82 27 a108 6 (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 a113 63 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 (FIXME reality currently is ) 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. "binaryat