You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 
Dr. Ralf S. Engelschall 51684a6faa upgrade to cURL 7.10.5 23 years ago
..
README
aux.prereq.sh Gentoo Linux support 23 years ago
aux.usrgrp.sh Fix dev ticket 23 by finally implementing {m,r,n,s}uid and {m,r,n,s}gid params 23 years ago
aux.wrapbin.sh Fix dev ticket 23 by finally implementing {m,r,n,s}uid and {m,r,n,s}gid params 23 years ago
aux.wrapsrc.sh
curl.patch
db.patch
dot.bash_login
dot.bashrc
local.README
lsync
lsync.8
lsync.pod
make.patch
mkproxyrpm.pl Support for MacOS X (at least 10.0.4) - now I know what the guys at Apple meant with "Think different" ;-) 23 years ago
openpkg.boot - RedHat 8 support (avoid problems due to alias rm='rm -i') - clean up temp dir 23 years ago
openpkg.pgp
openpkg.spec upgrade to cURL 7.10.5 23 years ago
rc
rc.conf
rc.func
rc.openpkg
root.README
rpm.patch.bugfix Support for MacOS X (at least 10.0.4) - now I know what the guys at Apple meant with "Think different" ;-) 23 years ago
rpm.patch.feature Support for MacOS X (at least 10.0.4) - now I know what the guys at Apple meant with "Think different" ;-) 23 years ago
rpm.patch.porting Support for MacOS X (at least 10.0.4) - now I know what the guys at Apple meant with "Think different" ;-) 23 years ago
rpm.patch.regen Support for MacOS X (at least 10.0.4) - now I know what the guys at Apple meant with "Think different" ;-) 23 years ago
rpmmacros allow only 'use_<toolname>' instead of 'with_<toolname>' for overriding 'l_<toolname>' to reduce conflict with regular package options 23 years ago
rpmpopt
rpmrc
rpmtool Support for MacOS X (at least 10.0.4) - now I know what the guys at Apple meant with "Think different" ;-) 23 years ago
rpmtool.8
rpmtool.pod
rpmx.pl teach --fetch to honor proxy settings 23 years ago
rpmx.sh Support for MacOS X (at least 10.0.4) - now I know what the guys at Apple meant with "Think different" ;-) 23 years ago
shtool make sure 'shtool subst' does not fail if file is not writeable due to permissions 23 years ago

README


OpenPKG Source Code Tree
========================

This is the source code tree for the OpenPKG bootstrap package. What
you find here is rather complex and tricky stuff, so don't be confused
if you don't understand everything immediately.

The Files
---------

README .................. this file ;)

openpkg.boot ............ the bootstrapping procedure
openpkg.spec ............ the build procedure

gzip-1.3.5.tar .......... untouched distribution tarball of the GNU gzip tool
make-3.80.tar.gz ........ untouched distribution tarball of the GNU make tool
make.patch .............. patch for GNU make
patch-2.5.4.tar.gz ...... untouched distribution tarball of the GNU patch tool
bash-2.05b.tar.gz ....... untouched distribution tarball of the GNU bash tool
tar-1.13.25.tar.gz ...... untouched distribution tarball of the GNU tar tool
curl-7.10.2.tar.gz ...... untouched distribution tarball of the cURL tool
curl.patch .............. patch for cURL tool

rpm-4.0.2.tar.gz ........ distribution tarball of the RPM tool
rpm-4.0.2.patch.bugfix .. patch for RPM (bugfixing parts)
rpm-4.0.2.patch.feature . patch for RPM (new features parts)
rpm-4.0.2.patch.porting . patch for RPM (portability enhancement parts)
rpm-4.0.2.patch.regen ... patch for RPM (re-generated files parts)
db-3.2.9.tar.gz ......... untouched distribution tarball of the Berkeley-DB library
db.patch ................ patch for Berkeley-DB library
bzip2-1.0.2.tar.gz ...... untouched distribution tarball of the BZIP2 library
zlib-1.1.4.tar.gz ....... untouched distribution tarball of the ZLIB library

rpmpopt ................. extensions for RPM's popt configuration
rpmrc ................... replacements for RPM's run-commands
rpmmacros ............... replacements for RPM's macros

root.README ............. the <root>/README file for the installation area
local.README ............ the <root>/local/README file for the installation area
dot.bashrc .............. the <root>/.bashrc file
dot.bash_login .......... the <root>/.bash_login file
dot.lsyncrc ............. the <root>/local/.lsyncrc file

rc ...................... the run-command handling script
rc.func ................. the run-command function definitions
rc.conf ................. the run-command configuration template
rc.openpkg .............. the run-command script for the OpenPKG hierarchy

rpmtool ................. the rpmtool tool (program source)
rpmtool.8 ............... the rpmtool tool (manual page)
rpmtool.pod ............. the rpmtool tool (manual page source)
lsync ................... the lsync tool (program source)
lsync.8 ................. the lsync tool (manual page)
lsync.pod ............... the lsync tool (manual page source)

aux.wrapsrc.sh .......... wrapper script for generating openpkg-X.X-X.src.sh
aux.wrapbin.sh .......... wrapper script for generating openpkg-X.X-X.YYY-YYYY-ZZ.sh
aux.usrgrp.sh ........... user/group name/id determination script
aux.prereq.sh ........... prerequisite checking script

openpkg.pgp ............. the OpenPGP public key of "The OpenPKG Project"

shtool .................. the pre-generated GNU shtool program

rpmx.sh ................. RPM eXtension (Shell wrapper)
rpmx.pl ................. RPM eXtension (Perl program)
mkproxyrpm.pl ........... RPM eXtension (Perl program, --makeproxy part)

The Bootstrapping Procedure
---------------------------

The complexity of this RPM package results from the fact that we force
us to treat RPM equal to every other package. This implies first that
RPM itself is an RPM package (means: its build procedure is a RPM
spec-file and it can be installed and upgraded through a binary or
source RPM), second that RPM is installed into the same filesystem
hierarchy as all other packages and third that RPM manages its own
files. The reason for this should be obvious: 100% consistency for the
whole software package facility!

The drawback is that the RPM package requires a very tricky
bootstrapping procedure which had cost a lot of time to figure out
and establish. If you ever wanted to know the gory details, here they
are...

The first step was that we wrote the regular openpkg.spec file for
building RPM with the assumption that RPM is already available. This
way we can provide RPM as an RPM package. Remains the problem how we
actually bootstrap in the case where RPM is still not available, i.e.,
when we reach a new platform. Here the openpkg.boot script comes into
play. It executes the openpkg.spec build procedure very similar to the way
RPM would do it. That is, openpkg.boot partly emulates RPM -- just enough
that openpkg.spec works. As a result, openpkg.spec cannot use any fancy RPM
features or other things before openpkg.boot is able to emulate it, of
course.

After openpkg.boot executed the %prep, %build and %install scripts of
openpkg.spec, there is a fresh version of the target filesystem hierarchy
staying under a temporary build root. The openpkg.boot script then creates
a very special temporary "rpm" command which allows the installed
"rpm" command inside the build root to work (although it is built for
the final target filesystem path). Then the RPM_BOOT variable is set
and the RPM package is again "built" via openpkg.spec -- but this time
with the real RPM tool. To avoid unneccessary re-compilation, the
openpkg.spec skips %prep, %build and %install if RPM_BOOT is defined, so
on this second build phase, only %files is executed, i.e., a binary
RPM openpkg-X.X-X.YYYY-YYYYYY-ZZ.rpm is rolled from the files in the
build root. Additionally a source RPM openpkg-X.X-X.src.rpm is rolled
for consistency reasons.

Finally we override the installation in the build root again by
installing the now rolled binary RPM -- again by using the real RPM
tool. This way we achieve that RPM is remembered as an RPM package
in its own database. We just have to make sure the package is still
relocated to the build root while installing. For this we could
use --prefix=$RPM_BUILD_ROOT/%{l_prefix}, but this would create an
incorrect filelist for "rpm" in the database. Instead we use the
tricky --justdb option for "rpm" which means "rpm" behaves as it
would install into the real location, but does not actually install
anything. But as a side-effect, the database inside the build root is
now correct.

After this procedure, the build root contains the target filesystem
hierarchy with RPM installed with itself. What is now remaining is to
roll a bootstrap package with this stuff for initial installation. For
this the build root is packed into a tarball, uuencoded, and finally
wrapped into a self-extracting shell script. The result is the binary
bootstrap script openpkg-X.X-X.YYYY-YYYYYYY-ZZ.sh which can be used
to bootstrap the target hierarchy from scratch. If one later wants to
upgrade this hierarchy one uses openpkg-X.X-X.YYYY-YYYYYYY-ZZ.rpm.

To allow one to easily repeat this from-source bootstrapping procedure
on other machines, one can run "./openpkg.boot -s" which rolls a
openpkg-X.X-X.src.sh script which is a self-extracting script containing a
tarball of this directory. This script is like openpkg-X.X-X.src.rpm, but
for bootstrapping situations.

Platforms and Level of Support
------------------------------

Operating System Fully Supported Partially Supported Known to work
----------------------- --------------- ------------------- -------------
FreeBSD (ix86) 4.7, 5.0 4.[0-6] -
Debian GNU/Linux (ix86) 3.0, 2.2 - -
RedHat Linux (ix86) - 7.[0-2], 8.0 -
Solaris (SPARC64) 8, 9 2.6, 7 -
Solaris (ix86) - - 2.8
NetBSD (ix86) - - 1.5.[0-2], 1.6
OpenBSD (ix86) - - 2.9
HP-UX (PA/IPF) - - 10.20
Tru64 (ix86) - - 5.0A, 5.1A
UnixWare - - -
Darwin - - -
Cygwin - - -
IRIX - - -
AIX - - -