head 1.41; access; symbols; locks; strict; comment @# @; 1.41 date 2004.02.24.10.46.32; author thl; state Exp; branches; next 1.40; 1.40 date 2004.02.05.12.44.21; author thl; state Exp; branches; next 1.39; 1.39 date 2004.01.29.10.02.00; author thl; state Exp; branches; next 1.38; 1.38 date 2004.01.21.09.41.13; author thl; state Exp; branches; next 1.37; 1.37 date 2004.01.16.18.06.00; author cs; state Exp; branches; next 1.36; 1.36 date 2004.01.16.17.58.14; author ms; state Exp; branches; next 1.35; 1.35 date 2004.01.14.12.10.56; author ms; state Exp; branches; next 1.34; 1.34 date 2004.01.14.11.02.04; author ms; state Exp; branches; next 1.33; 1.33 date 2004.01.14.09.19.43; author cs; state Exp; branches; next 1.32; 1.32 date 2003.11.18.09.25.07; author ms; state Exp; branches; next 1.31; 1.31 date 2003.11.14.13.00.02; author ms; state Exp; branches; next 1.30; 1.30 date 2003.08.14.17.19.16; author mlelstv; state Exp; branches; next 1.29; 1.29 date 2003.07.29.18.21.27; author ms; state Exp; branches; next 1.28; 1.28 date 2003.07.16.10.58.59; author rse; state Exp; branches; next 1.27; 1.27 date 2003.06.02.14.04.15; author rse; state Exp; branches; next 1.26; 1.26 date 2003.05.09.13.50.03; author ms; state Exp; branches; next 1.25; 1.25 date 2003.04.22.13.52.07; author ms; state Exp; branches; next 1.24; 1.24 date 2003.03.06.13.18.18; author ms; state Exp; branches; next 1.23; 1.23 date 2003.02.26.11.10.57; author ms; state Exp; branches; next 1.22; 1.22 date 2003.01.21.11.13.55; author ms; state Exp; branches; next 1.21; 1.21 date 2003.01.03.18.04.00; author rse; state Exp; branches; next 1.20; 1.20 date 2002.12.31.07.27.50; author rse; state Exp; branches; next 1.19; 1.19 date 2002.12.04.09.31.12; author ms; state Exp; branches; next 1.18; 1.18 date 2002.12.03.17.50.29; author ms; state Exp; branches; next 1.17; 1.17 date 2002.11.28.20.24.55; author ms; state Exp; branches; next 1.16; 1.16 date 2002.11.05.14.50.26; author ms; state Exp; branches; next 1.15; 1.15 date 2002.10.08.07.17.58; author ms; state Exp; branches; next 1.14; 1.14 date 2002.08.14.07.10.02; author ms; state Exp; branches; next 1.13; 1.13 date 2002.08.05.15.53.02; author ms; state Exp; branches; next 1.12; 1.12 date 2002.07.01.10.22.17; author openpkg-cvs; state Exp; branches; next 1.11; 1.11 date 2002.07.01.10.14.03; author openpkg-cvs; state Exp; branches; next 1.10; 1.10 date 2002.05.24.12.56.45; author openpkg-cvs; state Exp; branches; next 1.9; 1.9 date 2002.03.26.15.58.53; author ms; state Exp; branches; next 1.8; 1.8 date 2002.03.08.16.08.00; author ms; state Exp; branches; next 1.7; 1.7 date 2002.03.08.14.40.20; author cs; state Exp; branches; next 1.6; 1.6 date 2002.03.08.14.37.38; author cs; state Exp; branches; next 1.5; 1.5 date 2002.03.06.18.09.22; author ms; state Exp; branches; next 1.4; 1.4 date 2002.02.22.13.52.48; author ms; state Exp; branches; next 1.3; 1.3 date 2002.02.19.14.24.57; author ms; state Exp; branches; next 1.2; 1.2 date 2002.02.19.12.44.19; author ms; state Exp; branches; next 1.1; 1.1 date 2002.02.06.13.29.51; author ms; state Exp; branches; next ; desc @@ 1.41 log @move prefix/tag info; move OS prereqs to a single location @ text @Jetzha - Binary und source Pakeln sind nicht exclusiv. - Unterschied zwischen current und release Pakeln. - Wie zu ueberpreufen daz ein Pakel recht sauber ist mittels MD5. - Section fuer Run-command Architecture, Verwendung, und Entwicklung fehlt. - Binary Pakheln soll nur fuer bootstrappen verwendbar werden (Erklaerung.) - More explanation on evaluation of OpenPKG environment variables. - Issues regarding the intrusion of OpenPKG into an undisturbed OS. Tie this point in with the new multiuser feature below *(ZZ.) o Point 1, .bashrc o Point 2, crontab(1) o Point 3, /etc/rc - Add section on how to pre-customize Apache building (rpm -bb.) - Using cron and dangers of /etc symlinking. - Clarify or maybe rename titles of sections Approach x, what are they? - Kapitel wegen vcheck und release engineering - Add chapter on 'How To Make a Package' and point or replace info in User section called 'The Lifecycle of a Package.' Schaumal openpkg Emaildatei. - Wie funktionieren Pakheln mit %externvars rpm --rebuild PakX --define with_X - Was sind vcheck Dateien, und wie helfen die uns alles Uptodate machen. - Warum gibts mehrere Pakheln in /current/ und was ist /release/ ueberhaupt? - Makefiles von src2make Skript. - Uebersicht von .rpmmacros und verfugbare Variabeln. - Pakherln Instance-abbreviation - Update how many packages (about 500?) - Java path standards (%{l_prefix}/lib/java/ CLASSPATH), add to rc.j2se - Write section on using rc, and understanding and modifying rc.X scripts o Maybe along with a general rc manpage? - Section on basics of openpkg-tool use Verschoben - Index. - Glossary. - Handbuch Build issues. - Split Porting to Developerkapitel General - Schau mal unter http://www.celestial.com/doc/openpkg/ fuer 3rd party Doku - Schreib mal Beispiele mehr. - support an "openpkg_ignall" variable for ignoring "all" type requests which can be used to disable an OpenPKG instance from startup/shutdown/cron but still being able to use it manually. This allows one to have an OpenPKG instance staying around but which is not activated. - more precise tarball rolling to get rid of the nasty uninstallation problem because of additionally staying around files from RPM. This solves the "rpm -e openpkg" problems under Solaris and other platforms where RPM installs additional files. Specfile Beschreibung 'Prefix:' The place where the package will ultimately be installed, and is the same for all packages in an OpenPKG instance. 'BuildRoot:' The fake directory where the software is fake installed during the build/packaging phase (see handbook). 'BuildPreReq:' Required packages before building from source is allowed. 'PreReq:' Required packages before binary installation is allowed. Using .rpmmacros to customize "How can i override the CFLAGS default for all packages?" You should be able to achieve this by overriding the l_cc and l_cflags variables in your ~/.rpmmacros. This is especially useful when bootstrapping platforms where OpenPKG does not initially find a C compiler in the path. %l_cc gcc (or) %l_cc /usr/local/bin/gcc %l_cflags -pipe -O3 -march=i686 -funroll-loops Alternatively, you can override %l_cc for a single rebuild by defining "use_cc". .../rpm --define "use_cc /usr/local/bin/gcc" --rebuild ... Macros in specfile OpenPKG's RPM additionally provides a set of local macros (C<%{l_xxx}>) to abstract system specifics and also help in removing redundancy from packaging specifications. For example, the C<%{l_prefix}> is the file system I of the associated OpenPKG instance. Using OpenPKG's local macros offers a clear advantage, because packages no longer need hard-coded path prefixes and can therefore be built for arbitrary OpenPKG instances. Macros exist for the most often used build variables. The C<%{l_cc}> macro expands to either IC (in case the OpenPKG C package is installed) or defaults to just C. The same goes for C<%{l_cflags -O}>: it expands to the optimized C compiler flags. In case C is installed, it expands to "C<-O2 -pipe>". Otherwise, it expands to just C<-O> by default. The variables C<%{l_make}> and C<%{l_mflags}> work together in a similar way. If C<%{l_make}> points to a known C which supports parallel building and the underlying system has more than one CPU, then C<%{l_mflags -O}> expands to the necessary flags to leverage the system's multiple processing power. For example, on a 2 CPU FreeBSD 4.x machine with BSD make, C<%{l_mflags -O}> expands to C<-j4 -B> while on a 4 CPU Linux machine with GNU make, C<%{l_mflags -O}> expands to C<--no-print-directory -j8>. Prerequisites in detail jdk-sun is based in JDK package from Sun which is available binary only (truely said there's also a source package but this requires existing JDK in order to build). Since this binary is linked against an old libstdc++ library. and we are forced to use a vendor package instead a own one. Furthermore we even don't have any version of libstdc++ as a OpenPKG package and I doubt that we want to have one. Von "Warnes, Gregory R" : I bootstrapped openpkg on Solaris 8 but had considerable problems building source packages until I discovered that on my system, BUFSIZ is defined to be 1024 in /usr/include/iso/stdio_iso.h, included from /usr/include/stdio.h. This is much smaller than the 8192 that (seems to be) the value that RPM expects (noted in the comments /Volumes/app/appman/RPM/SRC/rpm-4.0.2). The effect was that the long installation path name (not my choice), /net/gsun492/Volumes/app/appman/, was causing the __build_pre macro to overflow its buffer and get truncated, resulting in general havoc. (It seems likely that short paths (/cm/) would not cause the problem to occur.) On Tue, Aug 13, 2002, Miles Egan wrote: > 1. we want to make sure that all packages in an openpkg instance are built > by > the same compiler and we want to be able to specify that compiler on a > per-instance basis. > Not obvious, but possible (at least with OpenPKG-CURRENT and the forthcoming 1.1): Use a ~/.rpmmacros (in the home of the user who builds the packages) with "l_cc /path/to/your/cc" and perhaps "l_cflags -flags -of -your -cc". > 2. we want to be able to automatically rebuild an entire collection of rpms > from their source rpms. > Also not obvious, but possible (at least with OpenPKG-CURRENT and the forthcoming 1.1): Use the release engineering scripts you find under http://www.openpkg.org/cvsweb/cvsweb.cgi/openpkg-re/. In particular what you need us the src2make.pl script which is given the source RPMs. It generates a Makefile which allows you to build the corresponding binary RPMs. Solaris 8: Bootstrap from source with gcc and NO Sun cc? > [...] > %l_cc %{l_tool_locate cc} > to: > %l_cc /usr/local/bin/gcc > > I was then able to compile make, then gcc-3.2 from src.rpm files at > ftp.openpkg.org. After that, I reverted the above change in rpmmacros to > the original, and I was able to build rsync (libtool picked up > /usr/local/opkg/bin/cc, which seems to be a hard link to the same > binary as /usr/local/opkg/bin/gcc). > > So, > - is there a better way to do this? > - Could I have simply symlink'd /usr/local/opkg/bin/cc to > /usr/local/bin/gcc ? > - is there a 'from source' tutorial or other docs that I should've > read or should read? The official way is to use: $ rpm --rebuild --define "use_cc /usr/local/bin/gcc" rsync-*.src.rpm This on-the-fly overrites the l_cc variable. I think we should add this to the FAQ and/or the handbook because it certainly is the main pitfall in bootstrapping on Solaris. What I did (although I temporarily defined l_cc in rpmmacros until I got gcc built, it would be similar with the command line opts), was: - built make-*.src.rpm (because gcc-*src.rpm depends on it) using /usr/local/bin/gcc - built gcc-3.2*.src.rpm using /usr/local/bin/gcc - installed the resulting gcc-3.2*.rpm - built rsync-*src.rpm using the newly installed openpkg gcc-3.2 (this was just to test if the new gcc worked) - Now, I've rebuilt gcc-3.2-*.src.rpm using the openpkg gcc-3.2, and I plan on installing that (after uninstalling gcc-*.rpm). - after that, I plan on rebuilding rsync and various other src RPMs (probably make as well, though I might have to force it because of the gcc dependency) Rebuilding gcc with itself should be unneccessary as gcc does the same thing as part of its normal make (phase 1 of make is to build gcc with local compiler, phase 2 builds finall gcc with compiler from gcc). Avoiding this rebuild could save a lot of time. Rebuilding make with gcc is probably appropriate though. - RSE about the new "%option" stuff: 1. Package options are introduced with "%option " only. It is not allowed to just "%define ", because this way they are not "Provided". 2. "%option" directives _HAVE_ to be placed after the (usually first) .spec part where the "Name:" header is part of. This is because %option requires the definition of "Name:" for its own operation. 3. The effect of "%option " is a "%ifndef "+"%define "+"%endif" plus a "Provides: :: = ". The "%define" part is so that you can check for the option while building with '%if "%{}" == ""'+'%endif'. The "Provides" part is so that the package exports the option. 4. You can view the options a package provides via multiple ways: a) if you have foo.spec file, just run "grep '^%option' foo.spec" b) if you have a source or binary RPM foo*.rpm, run "rpm -qpi foo*.rpm" and watch under "Provides:" or run alternatively "rpm -qp --provides foo*rpm". For this to work also with source RPMs, I've this evening patched RPM, so don't be confused. c) if you have an installed foo package, run "rpm -qi foo" and watch under "Provides:" or run alternatively "rpm -q --provides foo". 5. As usual, you can set/override option values on the "rpm --rebuild" command line with "--define ' '". 6. As usual, another package can depend on the package via "[Build]PreReq: ". Additionally, it can also depend on to be build under option with by using "[Build]PreReq: :: == ". 7. Any package using %option _has_ to require at least "openpkg >= 20030103". ---- If userid and groupid text is still too vague, then consider roles: opkg This is the use/group set that would be used by normal users on the system, and the top level directory would have the appropriate permissions for their use. As an example, if the package were accounting related data that should only be accessible from the accounting group, the top level directory might have 750 permissions restricting access to people in that group. This group would only have write access in the appropriate data areas necessary to run the software. opkg-root This is the manager with full read/write permissions throughout the opkg tree. opkg-devel Developer access which would have read/write access to everything under the %{l_prefix}/RPM tree except for %{l_prefix}/RPM/DB where they would only have read access. -- Bill CAMPBELL, bill@@Celestial.com Package Variants ---------------- o Naming Convention - primary/intended package is named "foo" - secondary/alternative/compatibility/etc packages are named "fooN" where "N" is the compressed version string not longer than 2 or 3 digits. - examples: perl/perl56, gcc/gcc2/gcc33, mysql/mysql4, tomcat/tomcat4 o Alternative Packages - for using automatically handled package alternatives - packages conflict by default, because are true alternatives - intention is that packages are fully equal and compatible, any can be used, any is chosen - multiple existing packages is final solution and will remain in near future - multiple packages are of different products (only) Original Package: | Name: foo | Provides: FOO Alternative Packages: | Name: fooN | Provides: FOO | %install | ln -s $RPM_BUILD_ROOT%{l_prefix}/bin/fooN $RPM_BUILD_ROOT%{l_prefix}/bin/foo Examples: MTA, JDK, JRE, MOTIF, KSH, X11 o Faked Packages - for using manually enforced package alternatives - packages do not conflict by default, but on enforcement - intention is that packages are not fully compatible, only one particular should be used, others can be enfored - multiple existing packages is temporary solution and will certainly change in near future - multiple packages are of different versions of same product (only) Original Package: | Name: foo Faked Packages: | Name: fooN | %options with_foo no | %if "%{with_foo}" == "yes" | Provides: foo = %{version}-%{release} | %endif | %install | %if "%{with_foo}" == "yes" | ln -s $RPM_BUILD_ROOT%{l_prefix}/bin/fooN $RPM_BUILD_ROOT%{l_prefix}/bin/foo | %endif Examples: perl, gcc, mysql, gd, tomcat Script Execution ---------------- section install erase upgrade reinstall ------- ------- ------- ------- --------- %pre 1 - 2 2 %post 1 - 2 2 %preun - 0 1 - %postun - 0 1 - ("reinstall" is the case where one uses the --force option to rpm (-i or -U) to install the same version of the package that already is in the system. "-" means that the scriptlet will not be run in this phase) The order in which scripts are executed on a single package install: new-%pre $1=1 for new version of package being installed ... (all new files are installed and override old versions) new-%post $1=1 for new version of package being installed The order in which scripts are executed on a single package upgrade: new-%pre $1=2 for new version of package being installed ... (all new files are installed and override old versions) new-%post $1=2 for new version of package being installed old-%preun $1=1 for old version of package being removed ... (all old files are removed which are not part of the new package) old-%postun $1=1 for old version of package being removed The order in which scripts are executed on a single package erase: old-%preun $1=0 for old version of package being removed ... (all old files are removed which are not part of the new package) old-%postun $1=0 for old version of package being removed Bug submission -------------- Vinod Kutty: Is there some documentation on bug submission and if not, could some be added? In particular it would be nice if the following were clearly spelled out: - is the openpkg-dev list the standard place for replies from the openpkg team to submitted bugs? - is there a way to get cc'd on the initial submission (for my records) and/or subsequent followups? - how do I update a bug report (e.g. more diagnostic output, etc.)? Is it simply by using the correct string in the Subject? per this text from an automated reply I recently received: If you want to submit for information for this particular bug report, please include the string "PR#139" in your the mail "Subject" header. Import Pakherl -------------- > Could someone direct me to a tutorial/quicky FAQ item, something that > tells me how to create a "virtual package" to meet the MTA dependency? > If you build the OpenPKG import package with "rpm --rebuild --define 'with_mta yes' --define 'with_mta_path \ /path/to/your/sendmail' openpkg-import-*.src.rpm" you get an openpkg-import package which provides the "MTA" virtual package and later directs sudo to your external Postfix installation. Using the OpenPKG Package Repository ----------------------------------------- OpenPKG (UPD)ates are not patches but rather complete packages, and are as compatible as possible to the original package. When updating to a UPD package, get the newest version. Build and install it using normal OpenPKG practices. Look for new or possibly invalid config files in l_prefix/etc/_package_. Verify that the UPD package works with a run time test. @ 1.40 log @configure incorrectly assumes availability of g++ when gcc is found @ text @a382 162 -- Minimum operating system installation requirements ================================================== o FreeBSD tbd o Debian GNU/Linux 3.0 (aka woody) (still incomplete) For those installing XFree86, 'xlibs-dev' and 'xutils' are needed also o Debian GNU/Linux 3.1 (aka sarge) Considering a very minimal installation (no tasksel during setup) following Debian packages are required (plus their dependencies; list may not be complete): - binutils - cpp - gcc - gettext-base - libc6-dev - libdps1 - libfreetype6 - libpam0g-dev - libxaw7 - linux-kernel-headers - make - sharutils - xbase-clients - xfree86-common - xlibmesa3-gl - xlibmesa3-glu - xlibs - xlibs-dev - xutils o RedHat Enterprise Linux 3 AS There is a 'minimal installation set' option available in the graphical installer, but not in the text-based installer. To achieve the most minimal (yet functional) installation, use the graphical installer with only this option selected. This leads to the following package list: acl-2.2.3-1 apmd-3.0.2-18 ash-0.3.8-16 aspell-0.33.7.1-25 at-3.1.8-46 attr-2.2.0-1 authconfig-4.3.7-1 autofs-3.1.7-41 basesystem-8.0-2 bash-2.05b-29 bc-1.06-15 beecrypt-3.0.1-0.20030630 bind-utils-9.2.2-21 binutils-2.14.90.0.4-26 bzip2-1.0.2-11 bzip2-libs-1.0.2-11 chkconfig-1.3.8-3 comps-3es-0.20031007 coreutils-4.5.3-26 cpio-2.5-3 cracklib-2.7-22 cracklib-dicts-2.7-22 crontabs-1.10-5 cups-1.1.17-13.3.6 cups-libs-1.1.17-13.3.6 cyrus-sasl-2.1.15-3 cyrus-sasl-gssapi-2.1.15-3 cyrus-sasl-md5-2.1.15-3 cyrus-sasl-plain-2.1.15-3 db4-4.1.25-8 dev-3.3.8-1 devlabel-0.41.01-1 dhclient-3.0pl2-6.14 diffutils-2.8.1-8 dos2unix-3.1-15 dosfstools-2.8-10 dump-0.4b28-7 e2fsprogs-1.32-15 ed-0.2-33 eject-2.0.13-2 elfutils-0.89-1 elfutils-libelf-0.89-1 ethtool-1.8-2 expat-1.95.5-6 fbset-2.1-13 file-3.39-9 filesystem-2.2.1-3 findutils-4.1.7-9 finger-0.17-18 fontconfig-2.2.1-6.0 freetype-2.1.4-4.0 ftp-0.17-17 gawk-3.1.1-9 gdbm-1.8.0-20 gettext-0.11.4-7 glib-1.2.10-11.1 glib2-2.2.3-2.0 glibc-2.3.2-95.3 glibc-common-2.3.2-95.3 gmp-4.1.2-5 gnupg-1.2.1-4 gpm-1.19.3-27.2 grep-2.5.1-16 groff-1.18.1-27 grub-0.93-4 gzip-1.3.3-9 hdparm-5.4-1 hesiod-3.0.2-28 hotplug-2002_04_01-20 htmlview-2.0.0-10 hwdata-0.98-1 info-4.5-3 initscripts-7.31.6.EL-1 iproute-2.4.7-10 ipsec-tools-0.2.2-7 iptables-1.2.8-12 iptables-ipv6-1.2.8-12 iputils-20020927-11 irda-utils-0.9.15-1 isdn4k-utils-3.1-76 jfsutils-1.1.2-2 jwhois-3.2.2-1 kbd-1.08-10.1 kernel-2.4.21-4.EL kernel-pcmcia-cs-3.1.31-13 kernel-smp-2.4.21-4.EL kernel-utils-2.4-8.37 krb5-libs-1.2.7-19 krb5-workstation-1.2.7-19 krbafs-1.1.1-11 krbafs-utils-1.1.1-11 kudzu-1.1.21-1 less-378-11 lftp-2.6.3-3 lha-1.14i-10 libacl-2.2.3-1 libattr-2.2.0-1 libgcc-3.2.3-20 libgcj-3.2.3-20 libjpeg-6b-30 libpng-1.2.2-16 libstdc++-3.2.3-20 libtermcap-2.0.8-35 libtiff-3.5.7-13 libtool-libs-1.4.3-6 libuser-0.51.7-1 libwvstreams-3.70-10 lockdev-1.0.1-1.2 logrotate-3.6.9-1 logwatch-4.3.2-2 losetup-2.11y-31.1 lslk-1.29-8 lsof-4.63-4 lvm-1.0.3-15 m4-1.4.1-13 mailcap-2.1.14-1 mailx-8.1.1-31 make-3.79.1-17 MAKEDEV-3.3.8-1 man-1.5k-10 man-pages-1.60-4.1 mdadm-1.0.1-1 mgetty-1.1.30-3 mingetty-1.06-1 minicom-2.00.0-17.1 mkbootdisk-1.5.1-1 mkinitrd-3.5.13-1 mktemp-1.5-18 modutils-2.4.25-9.EL mount-2.11y-31.1 mtools-3.9.8-8 mtr-0.52-2 mt-st-0.7-11 nano-1.2.1-4 nc-1.10-18 ncompress-4.2.4-33 ncurses-5.3-9.3 netconfig-0.8.19-1 netdump-0.6.10-2 net-tools-1.60-20 newt-0.51.5-1 nfs-utils-1.0.5-3 nscd-2.3.2-95.3 nss_ldap-207-2 ntsysv-1.3.8-3 openldap-2.0.27-11 openssh-3.6.1p2-18 openssh-clients-3.6.1p2-18 openssh-server-3.6.1p2-18 openssl-0.9.7a-22.1 pam-0.75-51 pam_krb5-1.70-1 pam_smb-1.1.7-1 parted-1.6.3-29 passwd-0.68-3 patch-2.5.4-16 pax-3.0-6 pciutils-2.1.10-7 pcre-3.9-10 pdksh-5.2.14-21 perl-5.8.0-88.4 perl-Filter-1.29-3 pinfo-0.6.6-4 popt-1.8.1-4.2 portmap-4.0-56 ppp-2.4.1-14 prelink-0.3.0-6 procmail-3.22-9 procps-2.0.13-9.2E psacct-6.3.2-27 psmisc-21.3-1.RHEL.0 pspell-0.12.2-16.1 pyOpenSSL-0.5.1-8 python-2.2.3-5 python-optik-1.4.1-2 pyxf86config-0.3.5-1 quota-3.09-1 raidtools-1.00.3-7 rdate-1.3-2 rdist-6.1.5-30 readline-4.3-5 redhat-config-mouse-1.0.13-1 redhat-config-network-tui-1.2.58-1 redhat-config-securitylevel-tui-1.2.9-1 redhat-logos-1.1.14.3-1 redhat-lsb-1.3-3 redhat-menus-0.39-1 redhat-release-3ES-1 rhnlib-1.3-12 rhpl-0.110-1 rmt-0.4b28-7 rootfiles-7.2-6 rpm-4.2.1-4.2 rpmdb-redhat-3-0.20031007 rpm-python-4.2.1-4.2 rp-pppoe-3.5-4 rsh-0.17-17 rsync-2.5.6-20 schedutils-1.3.0-3 sed-4.0.7-3 sendmail-8.12.10-1 setarch-1.3-1 setserial-2.17-12 setup-2.5.27-1 setuptool-1.13-1 shadow-utils-4.0.3-7 sharutils-4.2.1-16 slang-1.4.5-18 slocate-2.6-9 specspo-3EL-1 star-1.5a08-4 stunnel-4.04-4 sudo-1.6.7p5-1 symlinks-1.2-18 sysklogd-1.4.1-12 syslinux-2.06-0.3E sysreport-1.3.7-1 SysVinit-2.85-4 talk-0.17-20 tar-1.13.25-13 tcpdump-3.7.2-7 tcp_wrappers-7.6-34 tcsh-6.12-4 telnet-0.17-26 termcap-11.0.1-17.1 tftp-0.32-4 time-1.7-23 tmpwatch-2.8.4-5 traceroute-1.4a12-20 tzdata-2003c-1 unix2dos-2.2-19 unzip-5.50-34 up2date-4.0.1-1 usbutils-0.11-1 usermode-1.68-5 utempter-0.5.2-16 util-linux-2.11y-31.1 vconfig-1.6-2 vim-common-6.2.98-1 vim-minimal-6.2.98-1 vixie-cron-3.0.1-74 wget-1.8.2-15 which-2.14-7 wireless-tools-26-2 words-2-21 wvdial-1.53-11 XFree86-libs-4.3.0-35.EL XFree86-libs-data-4.3.0-35.EL XFree86-Mesa-libGL-4.3.0-35.EL xinetd-2.3.12-2.3E ypbind-1.12-1 yp-tools-2.8-1 zip-2.3-16 zlib-1.1.4-8.1 Beside the packages in the 'mininal installation set', the following are required as well: - glibc-kernheaders-2.4-8.34.i386.rpm (RHEL 3 AS CD-ROM 3) - glibc-headers-2.3.2-95.3.i386.rpm (RHEL 3 AS CD-ROM 3) - glibc-devel-2.3.2-95.3.i386.rpm (RHEL 3 AS CD-ROM 3) - cpp-3.2.3-20.i386.rpm (RHEL 3 AS CD-ROM 2) - gcc-3.2.3-20.i386.rpm (RHEL 3 AS CD-ROM 3) - ncurses-devel-5.3-9.3.i386.rpm (RHEL 3 AS CD-ROM 3) - gcc-c++-3.2.3-20.i386.rpm (RHEL 3 AS CD-ROM 3) [*] - libstdc++-devel-3.2.3-20.i386.rpm (RHEL 3 AS CD-ROM 3) [*] required because some packages' configure incorrectly assume availability of g++ when gcc is found i.e. dmalloc-5.3.0-20040203 Pay attention to the bottom of the package selection list where one can choose these additional packages individually. Should the text-based installation option be used, all installation options (even X11) can be deselected. Although this does not lead to a minimal installation (!), it installs the operating system with much unnecessary software left out. The packages missing from the graphical installation method are missing here as well, and must be installed after the fact. X11 packages can later be installed likewise. For X11 development add the following packages: Glide3-20010520-25 XFree86-4.3.0-35.EL XFree86-Mesa-libGLU-4.3.0-35.EL XFree86-base-fonts-4.3.0-35.EL XFree86-devel-4.3.0-35.EL XFree86-font-utils-4.3.0-35.EL XFree86-tools-4.3.0-35.EL XFree86-xauth-4.3.0-35.EL XFree86-xfs-4.3.0-35.EL chkfontpath-1.9.10-1.RHEL desktop-file-utils-0.3-10 fontconfig-devel-2.2.1-6.0 freetype-devel-2.1.4-4.0 pkgconfig-0.14.0-5 switchdesk-3.9.8-17 ttmkfdir-3.0.9-6 xinitrc-3.32-1 o Sun Solaris 8 tbd o Sun Solaris 9 tbd -- Binary Package Releases OpenPKG binary packages are made available for each supported platform. These packages should in principle be ignored, as one of the pillars of OpenPKG integrity suggests building from source in every case. However, exceptions exist (see section blah...) in which a binary package is needed. Change in Released Binary Package Naming Scheme Previous to version 2.0, binary (release grade) packages were released. These packages will install to the '/cw' directory (see explanation cool world...). From version 2.0 on, binary packages are released but will install to a different directory '/openpkg'. This is meaningless to the admin who never uses binary packages according to OpenPKG recommendation. For those installing binary packages from OpenPKG version 2.0 and later, attention should be given to this change. For example, scripts installing OpenPKG 2.0 binary packages and later expecting the resulting software to be available in '/cw' will now fail. @ 1.39 log @iselect wanted /usr/include/curses.h on dv23 @ text @d478 5 @ 1.38 log @log current state of dv23 which is based on input from and communication between Christoph and Michael @ text @d477 1 @ 1.37 log @updated Debian 3.1 requirements @ text @d430 39 d487 19 @ 1.36 log @Add more details on debian and X11 requirements @ text @d399 23 a421 2 (still incomplete) For those installing XFree86, 'xlibs-dev' and 'xutils' are needed also @ 1.35 log @Add Redhat Enterprise AS requirements details, which are only approximately correct until further investigation proves or disproves them @ text @d394 2 a395 1 tbd d399 2 a400 1 tbd @ 1.34 log @Remember change of directory name for binary packages, and edit random device requirements text @ text @d402 7 a408 3 Beside the mininal installation set one can choose at the very bottom of the package selection list during initial OS installation, following packages are required additionally: d416 9 a424 2 Please note that the minimal installation set might not be available in the text-based installer but in the graphical one. @ 1.33 log @minimal OS requirements @ text @d422 25 @ 1.32 log @Help with navigation and general usage of the official OpenPKG package repository should be documented @ text @d383 39 @ 1.31 log @Remember more stuff to document @ text @d373 10 @ 1.30 log @reflect change in macro name (with_cc -> use_cc) @ text @d30 1 d358 14 @ 1.29 log @Add section on bugs, how to submit reports, and what to expect @ text @d71 2 a72 2 Alternatively, you can override %l_cc for a single rebuild by defining "with_cc". .../rpm --define "with_cc /usr/local/bin/gcc" --rebuild ... d159 1 a159 1 $ rpm --rebuild --define "with_cc /usr/local/bin/gcc" rsync-*.src.rpm @ 1.28 log @remember a few important things @ text @d337 21 @ 1.27 log @remember issues @ text @d305 32 @ 1.26 log @Update packages list and remember 3rd party documentation source @ text @d254 51 @ 1.25 log @Remember text describing rc and what it can do. @ text @d38 2 @ 1.24 log @Remember sections on build variables, macros, and CLASSPATH. @ text @d28 2 @ 1.23 log @Remember to write a paragraph on .rpmmacros and list variables and options. @ text @d27 1 d62 2 a63 1 variables in your ~/.rpmmacros d65 1 d67 25 @ 1.22 log @Clarify platforms and expected level of support. @ text @d26 1 d57 7 @ 1.21 log @remember issues for addition to handbook @ text @d31 1 d189 24 @ 1.20 log @remember issue @ text @d150 1 a150 2 - RSE: The syntax is: d152 3 a154 2 %option %options [-p] d156 32 a187 7 where "%option " is syntactically equivalent with "%ifndef %define %endif" plus remembering the string "%option %{}" in an internal macro. Then "%options" expands this internal macro back into the "%option " strings. If a is given, the part in "%option " is padding with spaces to a fixed width in order to get a nice aligned output in %description texts. @ 1.19 log @More info on recent user item is available. @ text @d150 14 @ 1.18 log @Remember user questions about bootstrapping with no C compiler. @ text @d144 6 @ 1.17 log @Remeber issue brought up on mailing list. @ text @d97 47 @ 1.16 log @Remember .rpmmacros explanation. @ text @d25 1 @ 1.15 log @The idea to improve the specfile description and construction advice. @ text @d24 1 @ 1.14 log @Make not-so-obvious things obvious again! @ text @d46 8 d74 1 a74 1 On Tue, Aug 13, 2002, Miles Egan wrote: @ 1.13 log @Fix a most subtle but serious error, which caused my Apache + ModSSL problems yesterday. Add BUFSIZE problem experiences as possible text. @ text @d66 21 @ 1.12 log @New platform and OS version topics. @ text @a7 1 - OpenPKG dependencies to mandatory existing tools clarification. d21 3 a23 57 - Requirements: uuencode, uuunencode, compress, uncompress, tar, sharutils? - Voll/Teil Unterstutzung fuer Red Hat, Debian 3, Solaris 9, und Mandrake? o Durch Bootstrap o Durch allen Packherln? o Unterschiedliche Requirements? o Installierungsmethode auf ein Solaris (ohne CC) Kiste? o FBSD 4.5 zum 4.6 Ueberall. Neue Multipackherl After some detailed discussions between Christoph and me, we decided today that we no longer cannot afford the "at any time, there is always just a single supported version of a package". Examples are GCC 3.x vs. 2.95.x, GD 1.x vs. 2.0.x, db 3.x vs. 4.0.x, apache 1.3.x vs. 2.0.x, etc. The reason why having multiple versions of a single packages (and why we avoided it until now) should be obvious: - redundancy in package specifications - visual inconsistency if compared with regular packages - conflicting installation files - ... Nevertheless at least the above packages require us to smooth this area and support it in some way. To avoid chaos we nevertheless have to force us into a few rules to play this game in a consistent way. Here they are: o Rule 0 (Dogma): We do not play the game if not absolutely necessary! If necessary we try to minimize the number of versions! The total number of packages involved in the game is restricted to "just a few" where "just a few" is currently defined to be <= 10. o Rule 1 (When): Multiple versions a package are accepted only for _major_ differences in vendor versions. Just minor and incompatible upgrades have to be solved differently within an OpenPKG release or branch. o Rule 2 (How): If multiple versions of package "foo" exists in a release or branch, they are provided as packages "foo" and "fooX" where "foo" has to be the _latest and stable_ (both conditions!) version and the "fooX" packages have to be either older versions or _newer and (still) unstable_ versions. The "X" in "fooX" is created out of the first (one or two, but never more!) numbers of the vendor version with punctuation characters stripped off. Examples: - gcc2-2.95.4, gcc-3.0.4 - db3-3.3.11, db-4.0.x - apache-1.3.32, apache2-2.0.32 - mysql-3.x.x, mysql4-4.0.x - freetype1-1.3.1, freetype-2.0.x o Rule 3 (Care): If possible, multiple version should be installable in parallel within same OpenPKG instance. If they conflict, they have to provide a reasonable Conflicts: header. a32 24 *(ZZ)Features - replace l_{fs,np}{usr,grp} with l_{s,m,r,n}{usr,grp} and create the two additional l_{r,n}{usr,grp} Unix accounts on bootstrapping. This way OpenPKG is a little bit more nasty (because requires 3 instead of 1 Unix uid/gid pair) but this is a very important cange because more and more packages require more distinguished uid/gids. Now OpenPKG packages can use: variables: purpose: login: owns: l_susr/l_sgrp super user yes everything l_musr/l_mgrp management user yes regular files l_rusr/l_rgrp restricted user no some files l_nusr/l_ngrp non-priviledged user no no files The default usually is: l_susr/l_sgrp = root/wheel l_musr/l_mgrp = cw/cw l_rusr/l_rgrp = cw-r/cw-r l_nusr/l_ngrp = cw-n/cw-n This allows us to finally upgrade to Postfix 1.1.3, Sendmail 8.12.2, etc. a46 24 - Debian GNU/Linux 2.2, minimal installation plus ... o gettext o libpam0g-dev o ncompress o sharutils A very few packages like jdk-sun require ... o libstdc++2.9-glibc2.1 - RedHat 6.x ? unknown - RedHat 7.2 ? unknown A very few packages like jdk-sun require ... compat-libstdc++-6.2 - Solaris 2.6, 7, 8 ? unknown, probably installation of developer meta cluster is required - FreeBSD ? unknown d54 12 a65 4 In case you really want to have a libstdc++ package we would need different ones links against different versions of glibc. Furhtermore these libs are required to be dynamically linked. This is not just a can of worms (as Ralf would call it :-). This would be *real* nightmare. @ 1.11 log @Remember to address requirements in detail. @ text @d23 6 @ 1.10 log @External variable calling from the rpm command line. @ text @d22 1 @ 1.9 log @Vcheck information for developer section. @ text @d21 1 @ 1.8 log @Clarify the part on jdk-sun and libstdc++ dependency. @ text @d17 1 @ 1.7 log @forgot the evil ;-) @ text @d141 11 @ 1.6 log @added a detailed list of vendor packages required by OpenPKG @ text @d126 9 @ 1.5 log @Remember change of packaging policy. @ text @d115 17 @ 1.4 log @Some things to remember from package building, and correct indentation. PR: Submitted by: Reviewed by: Approved by: Obtained from: @ text @d19 51 @ 1.3 log @Updated bison example, and corrected l_branch variable and alignment also. PR: Submitted by: Reviewed by: Approved by: Obtained from: @ text @d16 3 @ 1.2 log @Noticed an inconsistency with the handbook and implementation. PR: Submitted by: Reviewed by: Approved by: Obtained from: @ text @a15 1 - Remove nicht richtige l_branch variable in Beispiel. @ 1.1 log @Changed name TODO to 00TODO and added reminder to update handbook according to new user suite features added for OpenPKG 1.1. @ text @d10 1 d16 1 d26 1 a26 1 Features @