From fedora-docs-commits at redhat.com Sun Oct 2 13:00:23 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Sun, 2 Oct 2005 09:00:23 -0400 Subject: developer-guide Makefile,1.8,1.9 Message-ID: <200510021300.j92D0NDL032644@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/developer-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv32625 Modified Files: Makefile Log Message: Updated Makefile to current standards Index: Makefile =================================================================== RCS file: /cvs/docs/developer-guide/Makefile,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- Makefile 28 Jun 2005 22:28:53 -0000 1.8 +++ Makefile 2 Oct 2005 13:00:19 -0000 1.9 @@ -1,30 +1,26 @@ ############################################################################### -# Makefile for community charter +# Makefile for RHLP docs project # Created by: Tammy Fox -# Last edited by: Tammy Fox +# Last edited by: Tommy Reynolds # WARNING: need passivetex 1.24 for pdf generation to work # License: GPL # Copyright 2003 Tammy Fox, Red Hat, Inc. +# Copyright 2005 Tommy Reynolds, MegaCoder.com ############################################################################### -XSLPDF = ../docs-common/xsl/main-pdf.xsl -XSLHTML = ../docs-common/xsl/main-html.xsl -LANG = en -DOCNAME = developers-guide-$(LANG) -XMLFILE = $(DOCNAME).xml +LANGUAGES = en +DOCBASE = developers-guide +XMLEXTRAFILES-en = ###################################################### include ../docs-common/Makefile.common ###################################################### -html: - @xmlto html -x $(XSLHTML) -o $(DOCNAME) $(XMLFILE) - @mkdir -p $(DOCNAME)/stylesheet-images - @cp ../docs-common/stylesheet-images/*.png $(DOCNAME)/stylesheet-images - @cp ../docs-common/css/fedora.css $(DOCNAME) -pdf: - @xmlto pdf -x $(XSLPDF) $(XMLFILE) -###################################################### - -clean: - @rm -rfv *.html *.pdf *.tex $(DOCNAME) $(DOCNAME).tar.gz +# If you want to add additional steps to any of the +# targets defined in "Makefile.common", be sure to use +# a double-colon in your rule here. For example, to +# print the message "FINISHED AT LAST" after building +# the HTML document version, uncomment the following +# line: +#${DOCNAME}/index.html:: +# echo FINISHED AT LAST From fedora-docs-commits at redhat.com Mon Oct 3 02:32:10 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Sun, 2 Oct 2005 22:32:10 -0400 Subject: docs-common/packaging fedora-doc.desktop.in.common, NONE, 1.1 fedora-doc.omf.in.common, NONE, 1.1 fedora-doc.spec.in.common, NONE, 1.1 titlegrab.py, NONE, 1.1 Message-ID: <200510030232.j932WAfL023217@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/docs-common/packaging In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv23196/packaging Added Files: fedora-doc.desktop.in.common fedora-doc.omf.in.common fedora-doc.spec.in.common titlegrab.py Log Message: Some materials for automatic package building, nothing gold yet --- NEW FILE fedora-doc.desktop.in.common --- [Desktop Entry] Encoding=UTF-8 Categories=Application;Documentation;X-Red-Hat-Base; Name=@NAME@ GenericName=@NAME@ Exec=gnome-help file:///usr/share/fedora/doc/fedora-doc- at DOCBASE@/C/@DOCBASE at -en.xml Icon=icon-documentation.png Terminal=false Type=Application Comment=Official Fedora documentation --- NEW FILE fedora-doc.omf.in.common --- fedora-docs-list at redhat.com (Fedora Documentation Project) fedora-docs-list at redhat.com (Fedora Documentation Project) @TITLE@ @DATE@ Official Fedora Documentation: @TITLE@ @TITLE@ --- NEW FILE fedora-doc.spec.in.common --- # Fedora documentation specfile skeleton Summary: Fedora documentation: %{docbase} Name: fedora-doc-%{docbase} Version: %{version} Release: 1 License: FDL Url: http://fedora.redhat.com/projects/docs/ Source0: %{docbase}-%{version}.src.tar.gz Source1: %{name}-C.omf Source2: %{name}.desktop Group: Documentation BuildArch: noarch BuildRoot: %{_tmppath}/%{name}-%{version}-root Requires: scrollkeeper >= 0.3.11 Requires: fedora-doc-common BuildRequires: scrollkeeper BuildRequires: xmlto %description This package contains official the Fedora documentation %{docbase}. For more information, refer to the Fedora Documentation Project. %prep %setup -q -n %{docbase}-%{version} %{__sed} -i 's!../docs-common/!../../docs-common/!' \ $RPM_BUILD_DIR/%{docbase}-%{version}/%{docbase}-en.xml %build # Perhaps we will require an HTML chunked build here for use with KDE; # not sure yet. %install rm -rf $RPM_BUILD_ROOT install -d -m 755 $RPM_BUILD_ROOT/%{_datadir}/omf/%{name} install -m 644 %{SOURCE1} $RPM_BUILD_ROOT/%{_datadir}/omf/%{name} install -d -m 755 $RPM_BUILD_ROOT/%{_datadir}/fedora/doc/%{name}/C install -m 644 $RPM_BUILD_DIR/%{docbase}-%{version}/*.xml \ $RPM_BUILD_ROOT/%{_datadir}/fedora/doc/%{name}/C for d in `find -type d $RPM_BUILD_DIR/%{docbase}-%{version}` do dname=`basename ${d}` install -d -m 755 \ $RPM_BUILD_ROOT/%{_datadir}/fedora/doc/%{name}/C/${dname} install -m 644 $RPM_BUILD_DIR/%{docbase}-%{version}/${dname}/* \ $RPM_BUILD_ROOT/%{_datadir}/fedora/doc/%{name}/C/${dname} done install -d -m 755 $RPM_BUILD_ROOT/%{_datadir}/applications install -m 644 %{SOURCE2} \ $RPM_BUILD_ROOT/%{_datadir}/applications/%{name}.desktop %clean rm -rf $RPM_BUILD_ROOT %post scrollkeeper-update exit 0 %postun scrollkeeper-update exit 0 %files %defattr(-, root, root,-) %docdir %{_datadir}/fedora/doc/%{name} %{_datadir}/fedora/doc/%{name}/* %dir %{_datadir}/omf/%{name} %{_datadir}/omf/%{name}/* %{_datadir}/applications/%{name}.desktop %changelog --- NEW FILE titlegrab.py --- #!/usr/bin/python -d import sys import xml.dom.minidom from xml.dom.minidom import Node xml_files = sys.argv[1:] if xml_files == []: print "Usage: titlegrab.py xml_file..." sys.exit (2) for file in xml_files: doc = xml.dom.minidom.parse(file) title = "" for node in doc.getElementsByTagName("articleinfo"): T = node.getElementsByTagName("title") for node2 in T: for node3 in node2.childNodes: if node3.nodeType == Node.TEXT_NODE: title += node3.data if title == "": # Hmm, must not be an
then for node in doc.getElementsByTagName("bookinfo"): T = node.getElementsByTagName("title") for node2 in T: for node3 in node2.childNodes: if node3.nodeType == Node.TEXT_NODE: title += node3.data print title From fedora-docs-commits at redhat.com Mon Oct 3 02:35:40 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Sun, 2 Oct 2005 22:35:40 -0400 Subject: example-tutorial Makefile,1.11,1.12 Message-ID: <200510030235.j932ZeEX023280@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/example-tutorial In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv23259 Modified Files: Makefile Log Message: Some ugly Makefile changes to test rpm buliding Index: Makefile =================================================================== RCS file: /cvs/docs/example-tutorial/Makefile,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- Makefile 17 Sep 2005 14:41:42 -0000 1.11 +++ Makefile 3 Oct 2005 02:35:37 -0000 1.12 @@ -26,3 +26,68 @@ # line: #${DOCBASE}-en/index.html:: # echo FINISHED AT LAST + + +###################################################### +# Some packaging specific vars +VERSION=$(shell grep BOOKID $(DOCBASE)-en.xml | sed 's/ - $(VERSION)-1\n- Update to version $(VERSION)\n/' \ + $(SPECIN) > $(DOCSPEC) +# +# Fill in files +# FIXME: Needs to be multiplexed for LANGUAGES (see above) + cp $(OMFIN) $(DOCOMF) + cp $(DESKTOPIN) $(DOCDESKTOP) + for file in $(DOCOMF) $(DOCDESKTOP); do \ + sed -i 's/@VERSION@/$(VERSION)/g' $(DOCOMF) ; \ + sed -i 's/@DATE@/$(DATE)/g' $(DOCOMF) ; \ + sed -i 's/@TITLE@/$(TITLE)/g' $(DOCOMF) ; \ + sed -i 's/@DOCBASE@/$(DOCBASE)/g' $(DOCOMF) ; \ + done +# +# Do the build... +# + rpmbuild -bb -vv $(RPMFLAGS) $(DOCSPEC) + mv RPMS/noarch/*.rpm . + rpmbuild --clean --rmsource $(RPMFLAGS) $(DOCSPEC) + rm -rf {BUILD,RPMS,SOURCES,SPECS,SRPMS} + rm -rf $(DOCBASE)-$(VERSION) From fedora-docs-commits at redhat.com Mon Oct 3 02:38:14 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Sun, 2 Oct 2005 22:38:14 -0400 Subject: docs-common/packaging fedora-doc.desktop.in.common,1.1,1.2 Message-ID: <200510030238.j932cEMx023310@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/docs-common/packaging In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv23291 Modified Files: fedora-doc.desktop.in.common Log Message: Fix oopsie in desktop file Index: fedora-doc.desktop.in.common =================================================================== RCS file: /cvs/docs/docs-common/packaging/fedora-doc.desktop.in.common,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- fedora-doc.desktop.in.common 3 Oct 2005 02:32:06 -0000 1.1 +++ fedora-doc.desktop.in.common 3 Oct 2005 02:38:12 -0000 1.2 @@ -1,8 +1,8 @@ [Desktop Entry] Encoding=UTF-8 Categories=Application;Documentation;X-Red-Hat-Base; -Name=@NAME@ -GenericName=@NAME@ +Name=@TITLE@ +GenericName=@TITLE@ Exec=gnome-help file:///usr/share/fedora/doc/fedora-doc- at DOCBASE@/C/@DOCBASE at -en.xml Icon=icon-documentation.png Terminal=false From fedora-docs-commits at redhat.com Mon Oct 3 02:42:39 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Sun, 2 Oct 2005 22:42:39 -0400 Subject: example-tutorial Makefile,1.12,1.13 Message-ID: <200510030242.j932gdJP023349@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/example-tutorial In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv23330 Modified Files: Makefile Log Message: Test twice before you commit, stupid Index: Makefile =================================================================== RCS file: /cvs/docs/example-tutorial/Makefile,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- Makefile 3 Oct 2005 02:35:37 -0000 1.12 +++ Makefile 3 Oct 2005 02:42:37 -0000 1.13 @@ -77,12 +77,14 @@ # FIXME: Needs to be multiplexed for LANGUAGES (see above) cp $(OMFIN) $(DOCOMF) cp $(DESKTOPIN) $(DOCDESKTOP) - for file in $(DOCOMF) $(DOCDESKTOP); do \ - sed -i 's/@VERSION@/$(VERSION)/g' $(DOCOMF) ; \ - sed -i 's/@DATE@/$(DATE)/g' $(DOCOMF) ; \ - sed -i 's/@TITLE@/$(TITLE)/g' $(DOCOMF) ; \ - sed -i 's/@DOCBASE@/$(DOCBASE)/g' $(DOCOMF) ; \ - done + sed -i 's/@VERSION@/$(VERSION)/g' $(DOCOMF) + sed -i 's/@DATE@/$(DATE)/g' $(DOCOMF) + sed -i 's/@TITLE@/$(TITLE)/g' $(DOCOMF) + sed -i 's/@DOCBASE@/$(DOCBASE)/g' $(DOCOMF) + sed -i 's/@VERSION@/$(VERSION)/g' $(DOCDESKTOP) + sed -i 's/@DATE@/$(DATE)/g' $(DOCDESKTOP) + sed -i 's/@TITLE@/$(TITLE)/g' $(DOCDESKTOP) + sed -i 's/@DOCBASE@/$(DOCBASE)/g' $(DOCDESKTOP) # # Do the build... # From fedora-docs-commits at redhat.com Mon Oct 3 02:46:07 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Sun, 2 Oct 2005 22:46:07 -0400 Subject: example-tutorial Makefile,1.13,1.14 Message-ID: <200510030246.j932k7f7023410@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/example-tutorial In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv23387 Modified Files: Makefile Log Message: Properly clean up rpm packages Index: Makefile =================================================================== RCS file: /cvs/docs/example-tutorial/Makefile,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- Makefile 3 Oct 2005 02:42:37 -0000 1.13 +++ Makefile 3 Oct 2005 02:46:04 -0000 1.14 @@ -49,7 +49,7 @@ clean:: - rm -rf $(DOCBASE)*.rpm + rm -rf fedora-doc-$(DOCBASE)*.rpm rpm: clean From fedora-docs-commits at redhat.com Tue Oct 4 01:43:26 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:43:26 -0400 Subject: rpm-guide Makefile,NONE,1.1 Message-ID: <200510040143.j941hQnA000330@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv312 Added Files: Makefile Log Message: --- NEW FILE Makefile --- ############################################################################### # Makefile for RHLP docs project # Created by: Tammy Fox # Last edited by: Tammy Fox # WARNING: need passivetex 1.24 for pdf generation to work # License: GPL # Copyright 2003 Tammy Fox, Red Hat, Inc. ############################################################################### LANGUAGES = en DOCBASE = rpm-guide XMLEXTRAFILES-en = ###################################################### include ../docs-common/Makefile.common ###################################################### $(DOCNAME)/index.html:: mkdir -p $(DOCNAME)/figs cp figs/*.png figs/*.eps $(DOCNAME)/figs From fedora-docs-commits at redhat.com Tue Oct 4 01:44:22 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:44:22 -0400 Subject: rpm-guide rpm-guide-advanced-packaging-en.xml,NONE,1.1 Message-ID: <200510040144.j941iMJx000359@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv341 Added Files: rpm-guide-advanced-packaging-en.xml Log Message: --- NEW FILE rpm-guide-advanced-packaging-en.xml --- Advanced RPM Packaging Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Chapter *Defining package dependency information *Setting triggers *Writing verification scripts *Creating subpackages *Creating relocatable packages *Defining conditional builds The previous chapter introduced the RPM spec file, which controls how RPM packages are built and installed. This chapter delves into advanced spec file topics such as using conditional commands and making relocatable packages, starting with how to specify package dependencies. Defining Package Dependencies Dependencies are one of the most important parts of the RPM system. The RPM database tracks dependencies between packages to better allow you to manage your system. A dependency occurs when one package depends on another. The RPM system ensures that dependencies are honored when upgrading, installing, or removing packages. From that simple concept, RPM supports four types of dependencies: *Requirements, where one package requires a capability provided by another *Provides, a listing of the capabilities your package provides *Conflicts, where one package conflicts with a capability provided by another *Obsoletes, where one package obsoletes capabilities provided by another, usually used when a package changes name and the new package obsoletes the old name Cross Reference Chapter 6 covers more on dependencies. The Obsoletes dependencies are usually only used when a package is renamed, such as the apache package becoming the httpd package, starting in Red Hat Linux 8.0. The httpd package obsoletes the apache package. You can list all of these dependencies in your spec file. The most commonly used dependency information, though, is what a package requires. Naming dependencies In your spec files, you can name the dependencies for your package. The basic syntax is: Requires: capability In most cases, the capability should be the name of another package. This example sets up a requires dependency. This means that the package requires the given capability. Use a similar syntax for the other kinds of dependencies: Provides: capability Obsoletes: capability Conflicts: capability You can put more than one capability on the dependency line. For example: Requires: bash perl You can use spaces or commas to separate the capabilities. For example: Requires: bash, perl Specifying the Version of the Dependencies You can also add version information, for example: Requires: bash >= 2.0 This states that the package requires the capability bash (a package) at version 2.0 or higher. The same logic applies to the other types of dependencies. For example: Conflicts: bash >= 2.0 This example states that the package conflicts with all versions of bash 2.0 or higher. Table 11-1 lists the version comparisons you can use. Table 11-1 Dependency version comparisons Comparison Meaning package < version A package with a version number less than version package > version A package with a version number greater than version package >= version A package with a version number greater than or equal to version package <= version A package with a version number less than or equal to version package = version A package with a version number equal to version package A package at any version number RPM supports an extended version number syntax for comparisons. The full format follows: Epoch:Version-Release For example: 1:5.6.0-17 In this case, the epoch is 1, the version 5.6.0, and the release is 17. In most cases, you will need just the version number. The epoch allows for handling hard-to-compare version numbers. The release number is almost never used. This makes sense, in that it ties a dependency to a particular build of the RPM package, rather than a version of the software itself. This type of dependency would only be useful if you drastically changed the way you build a package. Creating Virtual CAPABILITIES Dependencies are based on capabilities, most of which are packages. You can create virtual capabilities, which are just names you define. For example, the sendmail package provides a virtual capability named smtpdaemon. For example: Provides: smtpdaemon This capability refers to the general SMTP Internet service for sending e-mail messages. There is no file of this name. Instead, it is just a capability, arbitrary text. Other packages require this capability, such as the fetchmail mail-retrieval and forwarding application, and mutt, an e-mail client program. By using a virtual capability, other packages can provide the capability, and most importantly, client applications can require the capability without worrying which package provides the ability to send e-mail messages. For example, the exim and postfix packages, mail transport agents like sendmail, can provide the same capability. Note Of course, you want to ensure that these packages specify that they conflict with each other. Naming Dependencies on Script Engines and Modules Scripting languages such as Perl and Tcl allow for add-on modules. Your package may require some of these add-on modules. RPM uses a special syntax with parenthesis to indicate script module dependencies. For example: Requires: perl(Carp) >= 3.2 This indicates a requirement for the Carp add-on module for Perl, greater than or equal to version 3.2. Setting prerequisites A prerequisite is similar to a require dependency, except that a prerequisite must be installed prior to a given package. Specify a prerequisite as follows: PreReq: capability You can include version-number dependencies, such as: PreReq: capability >= version In most usage, a PreReq: acts just like Requires:, in fact, the PreReq: directive exists just to allow for a manual order to dependencies. RPM guarantees that the PreReq: package will be installed prior to the package that names the PreReq: dependency. Cross Reference Chapter 14 covers a common problem of handling circular dependencies using prerequisites. Naming build dependencies Your package, once built, has a set of dependencies. These dependencies are important for anyone installing the package. But there are also dependency issues when trying to build packages. Build dependencies allow you to specify what is necessary to build the package. While you may think this would be the same as what is needed to install a package, this is normally not true. Linux distributions tend to divide up software into runtime and development packages. For example, the python package contains the runtime for executing scripts written in Python. The python-devel package provides the ability to write extensions to the Python language. RPM allows you to define build-time dependencies in your spec files using the following directives: BuildRequires: BuildConflicts: BuildPreReq: These directives act like Requires:, Conflicts:, and PreReq:, respectively, except that the dependencies are needed to build the package, not install it. For example, your package may require a C compiler to build, or may need a special build tool or developer library. Generating dependencies automatically Because so many dependencies are related to shared libraries, the RPM system will automatically generate provide dependencies for any file in your packages that is a shared object, or .so, file. RPM will also automatically generate require dependencies for all files in the %files list that require shared libraries. To do this, RPM uses the ldd command, which determines the shared libraries used by an application. In addition, the find-requires and find-provides scripts in /usr/lib/rpm can determine Perl, Python and Tcl script dependencies and other dependencies, such as Java package dependencies, automatically. The find-requires script determines requires dependencies automatically, and the find-provides script determines provides dependencies. Cross Reference Chapter 14 covers how to turn off the automatic generation of dependencies. Setting Triggers Triggers provide a way for one package to take action when the installed status of another package changes. A trigger is a script you define in your package???s spec file that gets run by the RPM system when the status of another named package changes. If your package depends in some way on another package, a trigger can allow your package to deal with changes to the other package. Triggers are not a replacement for package dependencies. Instead, triggers are useful when you need to change a package???s installation based on other packages installed on the system. For example, if your package is a mail client program, your package will need to have a mail transfer agent, or MTA. Linux supports a number of different mail transfer agents, such as sendmail, vmail, exim, qmail, and postfix. Typically a system will have one mail transfer agent installed. In most cases, a mail client won???t care which MTA is installed, as long as one is installed. (In fact, most of these packages should be marked that they conflict with one another, ensuring that a given system can only have one.) The %triggerin script is run when a given target package is installed or upgraded. The %triggerin script is also run when your package is installed or upgraded, should the target package be already installed. Similarly, the %triggerun script is run if the target package is removed. It is also run if your package is removed and the target package is installed. The %triggerpostun script is run after the target package has been removed. It is not run if your package is removed. To define one of these scripts, you need to list the name of the target package; for example: %triggerin -- tcsh script commands... This example sets up a trigger for the tcsh package. If the tcsh package is installed or upgraded, RPM will run the script. If your package is installed or upgraded and the tcsh package is presently installed, RPM will also run the script. Define the %triggerun script similarly: %triggerun -- tcsh script commands... You can also use version numbers in the trigger script definition to only run the script in the case of a particular version. For example: %triggerpostun -- vixie-cron < 3.0.1-56 /sbin/chkconfig --del crond /sbin/chkconfig --add crond This example, from the vixie-cron scheduling package, runs a post-uninstall trigger for the same package, but for older versions. To define trigger scripts for particular versions, use the same syntax as for requires dependencies for naming the version number and comparisons. Triggers are run through /bin/sh, the most commonly used shell script engine. With the -p option, though, you can specify a different script interpreter. For example, to write a Perl script, define your trigger like the following: %triggerpostun -p /usr/bin/perl -- vixie-cron < 3.0.1-56 system("/sbin/chkconfig --del crond"); system("/sbin/chkconfig --add crond"); With subpackages, defined following, you can use a -n option to tie the trigger script to a subpackage. For example: %triggerpostun -n subpackage_name -- vixie-cron < 3.0.1-56 /sbin/chkconfig --del crond /sbin/chkconfig --add crond Inside your trigger scripts, $1, the first command-line argument, holds the number of instances of your package that will remain after the operation has completed. The second argument, $2, holds the number of instances of the target package that will remain after the operation. Thus, if $2 is 0, the target package will be removed. The anonftp package, mentioned in Chapter 6, has a lot of triggers. Many of these set up a number of commands to be locally available to the anonftp package. This networking package is also closely tied to the version of the C library, glibc, as shown in Listing 11-1 Listing 11-1: Anonftp package trigger scripts. %triggerin -- glibc copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null | | cp -df "$file" "$2"; } # Kill off old versions rm -f /var/ftp/lib/ld-* /var/ftp/lib/libc* /var/ftp/lib/libnsl* /var/ftp/lib/lib nss_files* &>/dev/null || : # Copy parts of glibc, needed by various programs in bin. LIBCVER=`basename $(ls --sort=time /lib/libc-*.so |head -n 1) .so |cut -f2- -d-` copy /lib/ld-${LIBCVER}.so /var/ftp/lib copy /lib/libc-${LIBCVER}.so /var/ftp/lib copy /lib/libnsl-${LIBCVER}.so /var/ftp/lib copy /lib/libnss_files-${LIBCVER}.so /var/ftp/lib md5sum /var/ftp/lib/lib*-*.so /var/ftp/lib/libtermcap.so.*.*.* 2>/dev/null >/var /ftp/lib/libs.md5 chmod 0400 /var/ftp/lib/libs.md5 # Use ldconfig to build symlinks and whatnot. [ ! -e /var/ftp/etc/ld.so.conf ] && touch /var/ftp/etc/ld.so.conf /sbin/ldconfig -r /var/ftp %triggerin -- fileutils copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null | | cp -df "$file" "$2"; } copy /bin/ls /var/ftp/bin md5sum `ls /var/ftp/bin/* |grep -v bin.md5` >/var/ftp/bin/bin.md5 chmod 0400 /var/ftp/bin/bin.md5 %triggerin -- cpio copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null | | cp -df "$file" "$2"; } copy /bin/cpio /var/ftp/bin md5sum `ls /var/ftp/bin/* |grep -v bin.md5` >/var/ftp/bin/bin.md5 chmod 0400 /var/ftp/bin/bin.md5 %triggerin -- tar copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null | | cp -df "$file" "$2"; } copy /bin/tar /var/ftp/bin md5sum `ls /var/ftp/bin/* |grep -v bin.md5` >/var/ftp/bin/bin.md5 chmod 0400 /var/ftp/bin/bin.md5 %triggerin -- gzip copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null | | cp -df "$file" "$2"; } copy /bin/gzip /var/ftp/bin ln -sf gzip /var/ftp/bin/zcat md5sum `ls /var/ftp/bin/* |grep -v bin.md5` >/var/ftp/bin/bin.md5 chmod 0400 /var/ftp/bin/bin.md5 %triggerin -- libtermcap copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null | | cp -df "$file" "$2"; } rm -f /var/ftp/lib/libtermcap.so.*.*.* &>/dev/null || : copy '/lib/libtermcap.so.*.*.*' /var/ftp/lib md5sum /var/ftp/lib/lib*-*.so /var/ftp/lib/libtermcap.so.*.*.* 2>/dev/null >/var /ftp/lib/libs.md5 chmod 0400 /var/ftp/lib/libs.md5 # Use ldconfig to build symlinks and whatnot. [ ! -e /var/ftp/etc/ld.so.conf ] && touch /var/ftp/etc/ld.so.conf /sbin/ldconfig -r /var/ftp %triggerin -- ncompress copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null | | cp -df "$file" "$2"; } copy /usr/bin/compress /var/ftp/bin md5sum `ls /var/ftp/bin/* |grep -v bin.md5` >/var/ftp/bin/bin.md5 chmod 0400 /var/ftp/bin/bin.md5 %triggerpostun -- anonftp 4.0 if [ "$2" != 1 ] ; then # The user has multiple glibc packages installed. We can't read the # user's mind, so don't do anything. exit 0 fi copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null | | cp -df "$file" "$2"; } # Kill off old versions rm -f /var/ftp/lib/ld-* /var/ftp/lib/libc* /var/ftp/lib/libnsl* /var/ftp/lib/lib nss_files* &>/dev/null || : # Copy parts of glibc, needed by various programs in bin. LIBCVER=`basename /lib/libc-*.so .so | cut -f2- -d-` copy /lib/ld-${LIBCVER}.so /var/ftp/lib copy /lib/libc-${LIBCVER}.so /var/ftp/lib copy /lib/libnsl-${LIBCVER}.so /var/ftp/lib copy /lib/libnss_files-${LIBCVER}.so /var/ftp/lib copy /bin/ls /var/ftp/bin copy /bin/cpio /var/ftp/bin copy /bin/tar /var/ftp/bin copy /bin/gzip /var/ftp/bin ln -sf gzip /var/ftp/bin/zcat copy /usr/bin/compress /var/ftp/bin rm -f /var/ftp/lib/libtermcap.so.*.*.* &>/dev/null || : copy '/lib/libtermcap.so.*.*.*' /var/ftp/lib # Use ldconfig to build symlinks and whatnot. [ ! -e /var/ftp/etc/ld.so.conf ] && touch /var/ftp/etc/ld.so.conf /sbin/ldconfig -r /var/ftp # Generate md5sums for verifyscript md5sum /var/ftp/lib/lib*-*.so /var/ftp/lib/libtermcap.so.*.*.* 2>/dev/null >/var /ftp/lib/libs.md5 chmod 0400 /var/ftp/lib/libs.md5 md5sum `ls /var/ftp/bin/* |grep -v bin.md5` >/var/ftp/bin/bin.md5 chmod 0400 /var/ftp/bin/bin.md5 Writing Verification Scripts RPM automatically handles package verification, checking to see that the proper files are installed, and testing the files themselves for the proper size and other attributes. You may need to do more in your package, though, to ensure everything is properly set up. With RPM, you can: *Control the tests used to verify each file, as described in Chapter 10 *Create a verify script that performs other tests If you need to perform some other test to verify your package, such as check that a configuration file has a particular setting (and that the setting is valid), you can fill in the %verifyscript in the spec file. The %verifyscript acts much like the %pre or %post scripts, except that the %verifyscript gets executed during package verification. Fill in a %verifyscript as follows: %verifyscript your script commands .... Common %verifyscript actions are to check for an entry in a system configuration file, such as an init-time startup script or /etc/shells (which lists the available shells). These are files owned by other packages that may need to be properly modified for a package to be properly installed. If your package has a similar circumstance, write a %verifyscript. In your script, send all error output to stderr. Cross Reference See Chapter 5 for more on package verification. Creating Subpackages A spec file may define more than one package. This type of additional package is called a subpackage. Subpackages exist to handle cases where you don???t want to associate one spec file with one package. Instead, you can define multiple packages within the spec file, as needed. For example, you may want to build the runtime and developer packages together, or the client and server portions of an application using subpackages. Splitting large documentation sets into separate subpackages is also common. With subpackages, you get: *One spec file *One source RPM *One set of build commands *Multiple binary RPMs, one per package or subpackage In most cases, subpackages are created just as a means to partition the files produced by a package into separate packages. For example, you will often see development libraries and header files split into a separate package from the main application package. Sometimes documentation is split out into a separate package, or client and server applications are divided into separate packages. In the end, though, this usually results in shifting files into subpackages and nothing more. To define a subpackage within a spec file, you start with the %package directive. For example: %package sub_package_name By default, the name of the subpackage will be the name of the package, a dash, and the subpackage name provided with the %package directive. For example: %package server This example names a subpackage server, which is a real subpackage inside the telnet package. In this case, the name for the server subpackage will be telnet-server, that is, the naming format is package-subpackage. If you don???t want this naming format, you can use the ???n option to the %package directive to define an entirely new name, using the following syntax: %package -n new_sub_package_name For example: %package ???n my-telnet-server With the ???n option, you specify the full name for the subpackage. The RPM system will not prefix the name with the enclosing package name. Providing information for subpackages When you define a subpackage, you need to provide as many of the package information directives as you need, including at the least Summary:, Group:, and %description directives. Anything not specified will use the parent package???s value, such as the version. Place these directives after the %package directive. For example: %package server Requires: xinetd Group: System Environment/Daemons Summary: The server program for the telnet remote login protocol. The %description directive for subpackages requires the name of the subpackage using the following syntax: %description subpackage For example: %description server Telnet is a popular protocol for logging into remote systems over the Internet. The telnet-server package includes a telnet daemon that supports remote logins into the host machine. The telnet daemon is enabled by default. You may disable the telnet daemon by editing /etc/xinetd.d/telnet. If you used the ???n option with the %package directive, you need to repeat the ???n option with the %description directive. For example: %description ???n my-telnet-server Telnet is a popular protocol for logging into remote systems over the Internet. The telnet-server package includes a telnet daemon that supports remote logins into the host machine. The telnet daemon is enabled by default. You may disable the telnet daemon by editing /etc/xinetd.d/telnet. The same concept works for the %files section. You need a separate %files section for each subpackage. For example: %files server %defattr(-,root,root) %{_sbindir}/in.telnetd %{_mandir}/man5/issue.net.5* %{_mandir}/man8/in.telnetd.8* %{_mandir}/man8/telnetd.8* Again, if you used the ???n option with the %package directive, you need to repeat the ???n option with the %files section. For example: %files ???n my-telnet-server %defattr(-,root,root) %{_sbindir}/in.telnetd %{_mandir}/man5/issue.net.5* %{_mandir}/man8/in.telnetd.8* %{_mandir}/man8/telnetd.8* Defining scripts for subpackages Much as you define separate %files and %description sections for subpackages, you can also define install and uninstall scripts for subpackages. The syntax is similar to that for the %files and %description sections: %pre subpackage For example, Listing 11-2 shows the scripts from the VNC package. Listing 11-2: VNC package install and uninstall scripts. %post server if [ "$1" = 1 ]; then /sbin/chkconfig --add vncserver fi %preun server if [ "$1" = 0 ]; then /sbin/service vncserver stop >/dev/null 2>&1 /sbin/chkconfig --del vncserver fi %postun server if [ "$1" -ge "1" ]; then /sbin/service vncserver condrestart >/dev/null 2>&1 fi Building subpackages The build sections in the spec file serve double duty. These sections are used for building the main package as well as subpackages. This is one reason why there are so many options on the %setup macro. The %setup macro allows for selectively unpacking the sources, rather than the default option of unpacking all the sources. For example, the following %setup macro definition gives rpmbuild specific instructions for unpacking one source file: %setup ???D- T ???a 1 In this example, the ???D option disables the automatic deletion of the directory where the sources will be unpacked. This means any previous contents of this directory, perhaps for other subpackages, will be left alone. The ???T option disables the automatic unpacking of the source files, and the ???a 1 option specifies to only unpack the first source file. You may need to use options like these when working with subpackages. Though, in most cases, subpackages are just means to partition the package files into separate packages. In cases like this, you will likely not need any of these special %setup options. Cross Reference Chapter 10 covers the %setup macro and lists the available options. Creating Relocatable Packages A relocatable package allows a user to specify where to install the package. For example, if you build a package for Red Hat Linux, the normal directory for binary executable programs is /usr/bin. Other versions of Linux, though, may place executable programs into /opt/bin, for example. If your package forces the use of /usr/bin, then your package won???t work on these other systems. Cross Reference Chapter 19 covers using RPM on other versions of Linux. With a relocatable package, though, you allow the user to redefine the top-level directories for your package, such as changing from /usr/bin to /opt/bin in the previous example. Making relocatable packages is generally considered a good thing, as you make the user???s life easier. To set up a relocatable package, you need to: *Set up the prefix directives for the top-level directories *Define the files under the prefix directories Setting up the prefixes The Prefix: directive names a top-level directory as a prefix you can relocate to another directory. For example: Prefix: /usr This states that all files under /usr can be relocated to other directories by simply mapping /usr to some other directory, such as /opt, on the rpm command line when installing or upgrading the package. Note You can define more than one Prefix: directive to list more than one top-level directory. Define the files section When you use a Prefix: directive in your spec file, all files in the %files section must be under the directory named with the Prefix: directive. For example, from the jikes compiler package: Prefix: /usr ... %files %defattr(-,root,root) /usr/bin/jikes %doc /usr/doc/jikes-%{version}/license.htm %doc /usr/man/man1/jikes.1* In this example, all the files are under the /usr directory. All files in the %files section must be located under one of the Prefix: directories. If you have more than one top-level directory, such as /usr and /etc, define more than one Prefix: directive. For example: Prefix: /usr Prefix: /etc Cross Reference Chapter 4 covers how to install or upgrade packages into different directories using the --relocate and --prefix options. Problems creating relocatable packages Not all packages work well as relocatable packages. Some packages have files that simply must go into a certain location and are therefore not relocatable. Some packages have programs that are hard-coded to look for files in a particular location and therefore cannot be relocated elsewhere. Other packages have symbolic links that also may not be relocatable. Furthermore, your package may provide software that is referenced by other packages, in the known directories. Relocating such a package will disable other software packages, packages you may not even know about. If your packages face any of these problems, chances are that making the package relocatable is not a good idea. In addition, if you use the %doc directive with local file names, remember that RPM will make a package-specific documentation directory, normally under /usr/doc. For example: %doc README NEWS This may defeat your attempts to create a relocatable package, unless you have a Prefix: directive with /usr, because the normal location is under /usr/doc, and all files in the %files section must start with one of the directories named with Prefix: directives. Defining Conditional Builds With the ability to define macros inside spec files, and also to use macros defined elsewhere, you gain a lot of control over how your package gets built. You can go further, though, and use special directives to perform only certain commands based on certain conditions. This adds a powerful capability to your spec files, and also makes it much easier to do things like build for multiple versions of Linux or other operating systems, as well as handle various backwards-compatibility issues. To define conditional build commands, you need to create conditional constructs in your package???s spec file. In addition, you need to define macros that the conditional constructs use to determine whether or not to execute a set of spec file directives. Cross Reference See Chapter 21 for more on macro file locations, and Chapters 19 and 20 for more on using RPM on other versions of Linux and other operating systems, respectively. RPM supports a number of ways to make parts of your spec file enabled or disabled based on certain conditions. These include conditional macros, conditional blocks, and special directives based on the system architecture. Defining conditional macros You can use a special syntax to test for the existence of macros. For example: %{?macro_to_test: expression} This syntax tells RPM to expand the expression if the macro macro_to_test exists. If the macro macro_to_test does not exist, nothing will be output. You can also reverse this test. A leading exclamation point, !, tests for the non-existence of a macro: %{!?macro_to_test: expression} In this example, if the macro_to_test macro does not exist, RPM will expand the expression. If you want, you can omit the expression and just test for the existence of the macro. If it exists, RPM will use the value of the macro. If the macro does not exist, RPM will use nothing. For example: %build ./configure %{?_with_ldap} make In this case, if the _with_ldap macro exists, the value of that macro will get passed on the command line to the configure script. If the _with_ldap macro does not exist, nothing extra will be passed on the command line to the configure script. This is very important when creating commands to build or install packages. Cross Reference Many of the macros you will test this way are set up with the --with command-line parameter. See Chapter 19 for details. Using conditional blocks The %if macro enables all the directives up to the %endif directive, if the condition is true. This is much like scripting languages. For example: %if %{old_5x} %define b5x 1 %undefine b6x %endif In this case, if the %old_5x macro has a value, the test will be true and all the directives inside the block will get executed. A %else allows you to specify what to do if the test is not successful. For example: %if %{old_5x} %define b5x 1 %undefine b6x %else %define b6x 1 %undefine b5x %endif In this case, if the %old_5x macro has a value, then all the directives up to the %else will get executed. Otherwise, if the %old_5x macro has no value, the directives from the %else to the %endif will get executed. Again, use an exclamation point to negate the test. For example: %if ! %{old_5x} %define b5x 1 %undefine b6x %endif You can use a && for an AND test. For example: %if %{old_5x} && %{old_6x} %{error: You cannot build for .5x and .6x at the same time} %quit %endif Using architecture-based conditionals In addition to the general-purpose %if conditional directive, you can use special directives that test for processor architecture and operating system. The %ifarch directive enables all the directives up to the %endif directive, if the processor architecture matches the values you pass to the %ifarch directive. For example: %ifarch sparc %define b5x 1 %undefine b6x %endif This block will only get executed if the processor architecture is SPARC. Cross Reference Chapter 21 covers RPM architecture and operating system names. You can pass more than one architecture name, separated by commas or spaces. For example: %ifarch sparc alpha %define b5x 1 %undefine b6x %endif This example tests if the processor architecture is SPARC or Alpha. As with the %if directive, you can also use an %else, to cover all cases where the test is not true. For example: %ifarch sparc alpha %define b5x 1 %undefine b6x %else %define b6x 1 %undefine b5x %endif This example tests if the processor architecture is SPARC or Alpha. If so, the directives from the %ifarch to the %else are executed. If not, the directives from the %else to the %endif are executed. The %ifnarch directive reverses the %ifarch test. That is, %ifnarch tests if the architecture is not one of the values listed. The following example tests if the processor architecture is not an i386 or an Alpha. %ifnarch i386 alpha %define b5x 1 %undefine b6x %endif The %ifos directive tests for the operating system. For example: %ifos linux %define b5x 1 %undefine b6x %endif This example tests if the operating system is Linux. You can reverse the test with the %ifnos directive. For example: %ifnos irix %define b5x 1 %undefine b6x %endif This example tests if the operating system is not Irix. Summary This chapter covers advanced topics in creating packages. Dependencies are very important. You need to specify which packages or capabilities your package requires, so the RPM system can ensure that all requirements are met before allowing users to install the package. If you do not specify the dependencies properly, then you are defeating the integrity of the RPM system. In addition to specifying what your package requires, it is also important to specify other dependency information. For example, if your package conflicts with another package, you need to very clearly state this. E-mail and Web server packages often conflict with other servers of the same type. You can specify both package dependencies as well as build dependencies. For example, you may need certain developer libraries to build your package, but not to install it. These are build dependencies. To help manage dependencies between packages and system configuration issues, you can set up trigger scripts. A trigger is a script in your package that gets executed when another package is installed or removed. If your package, for example, is an e-mail client program, it may need to execute a script should the e-mail server package change. This is a great usage for triggers. If your package has a complicated installation, the normal RPM verification won???t be sufficient. To help the RPM system ensure the integrity of all the packages, you can write a verify script in your spec file to perform any extra commands necessary to verify your package has been properly installed. Relocatable packages allow users to install your packages in different locations than originally planned. This is very useful when working with more than one version of Linux, or with other operating systems. For example, most Linux commands are stored in /usr/bin, at least for Red Hat Linux. Other Linux distributions, or other operating systems may specify that programs added to the original set should be stored in /opt/bin and not /usr/bin, for example. Making your package relocatable helps users in these situations. Conditional directives in your spec file allow you to control the build on different processor architectures and operating systems. The %if directive tests if a value is set. If so, then all the directives up to the %endif directive are executed. If you need to execute a different set of directives, use %else. In this case, if the %if test is true, RPM executes the directives up to the %else. If the test is not true, RPM executes the directives up to the %endif. Once you have your spec file defined, the next step is to start building packages. The next chapter covers options for the rpmbuild command and how you can use rpmbuild to make your packages. From fedora-docs-commits at redhat.com Tue Oct 4 01:45:46 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:45:46 -0400 Subject: rpm-guide rpm-guide-command-reference-en.xml,NONE,1.1 Message-ID: <200510040145.j941jkc5000394@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv376 Added Files: rpm-guide-command-reference-en.xml Log Message: --- NEW FILE rpm-guide-command-reference-en.xml --- RPM Command Reference In This Appendix *rpm command *rpmbuild command This appendix covers the syntax of the command-line options for the rpm and rpmbuild commands. The rpm Command The rpm command is the workhorse of the RPM system. The following sections cover options for the major operations with the rpm command. Table A-1 lists the query options for the rpm command. Table A-1 rpm query options with ???q or --query Option Usage -a, --all Query all packages -c, --configfiles List configuration files --changelog List changelog entries --conflicts List capabilities this package conflicts with -d, --docfiles List documentation files --dump Dump out extra information on files. -f, --file filename Query for packages owning given file --filesbypapkg List all files in each selected package --fileid md5_id Query for the package with the given MD5 digest -g, --group group_name Query packages in the given group --hdrid sha1_header_id Query for the package with the given header identifier number, in SHA1 format -i, --info Display a lot of package information including description --last [...1918 lines suppressed...] Read the given colon-separated files as the macro files to define RPM macros; only the first file must exist --nobuild Don't really build anything, which really tests the spec file --pipe command Pipe the output of the rpm command to the given command --quiet Provide less output, normally show only errors --rcfile file:file:file Read the given colon-separated files as the rc files to define RPM settings; only the first file must exist --rmsource Remove the sources after the build --rmspec Remove the spec file after the build --root directory Use directory as the top-level directory instead of / --short-circuit With the -bc or -bi options, jumps directly to the given stage and just executes that stage --showrc Print the rpmrc and macro configuration and exit --sign Sign the package with a GPG signature --target platform Build for the given platform. May not work if you don't have the other platform build commands, such as cross compilers, set up. Can work for Intel platforms with i386, i686, and so on. -v, --verbose Provide more verbose output -vv Provide even more verbose output, including debugging information --version Print the RPM version and exit From fedora-docs-commits at redhat.com Tue Oct 4 01:48:22 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:48:22 -0400 Subject: rpm-guide rpm-guide-creating-rpms-en.xml,NONE,1.1 Message-ID: <200510040148.j941mMo0000423@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv405 Added Files: rpm-guide-creating-rpms-en.xml Log Message: --- NEW FILE rpm-guide-creating-rpms-en.xml --- Creating RPMs: An Overview Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Chapter *Preparing to build RPMs *Planning for RPMs *Explaining the build process *Using build files *Seeing the results *Verifying your RPMs Thus far in this book, all the commands presented have been used to manage or query packages. With this chapter, though, you start creating RPMs of your own. Even if you do not produce applications on your own, you may want to create RPM packages out of software you use, if only for the ease of management that the RPM system provides. Creating RPMs allows you to create a consistent set of applications for use on all systems in your organization and easily manage those applications. You may create RPMs of applications developed in house or RPMs of applications developed elsewhere that you need to customize for your environment. Making RPMs of the customized applications reduces work and makes the customizations consistent. This chapter introduces the RPM system from the point of view of creating RPMs and demonstrates the steps and planning necessary to make your own packages. As such, this chapter introduces the RPM-building topics covered in depth in the remaining chapters in this part. Preparing to Build RPMs The RPM-building task starts with gathering all the material you want to bundle into an RPM package and then defining the RPM directives to make your package. The final steps are to build and test an RPM. This sounds easy, and for the most part it is fairly straightforward. The main problems arise when you try to define the many RPM directives for your package. In addition, some of the elements in an RPM can be complex, such as upgrade scripts. The main tasks in building RPMs are: 1.Planning what you want to build 2.Gathering the software to package 3.Patching the software as needed 4.Creating a reproducible build of the software 5.Planning for upgrades 6.Outlining any dependencies 7.Building the RPMs 8.Testing the RPMs The sections in this chapter cover the initial planning stages and provide an overview of the process of building RPMs. The remaining chapters in Part II go in depth into the process of building RPMs. Planning what you want to build The first step in the entire RPM-building process is simply to decide exactly what you want to make into an RPM. Is this an application, a programming library, a set of system configuration files, or a documentation package? If this is an application, is it customized or patched? Think these issues over and decide what you want to package as an RPM. In most cases, you want to create both a source package and a binary package containing the built sources. You need a binary package because that holds the RPM you want to install on other systems. You need the source package so you can recreate the binary package at any time. And, if the sources get updated, you can quickly make a new binary RPM from the updated sources if you have already defined a source RPM. Most packages start with a source RPM, although you have the option to skip making a source RPM. It is a good idea to make the source RPM, however, because it makes it easier to reproduce the final binary RPM. Once of the key goals of the RPM system is to allow for reproducible builds, and making source RPMs is just one step to help towards this goal. Creating a source RPM also allows you to transfer the entire set of sources for a package to another system, since the source RPM is just one file and it contains all the program sources along with the instructions, called a spec file, for building the binary RPM. Furthermore, creating a source RPM makes it easier to create binary RPMs on different processor architectures or different versions of Linux. Note Not all programs are portable to multiple-processor architectures. But many Linux programs can simply be recompiled on another architecture to make a binary program for that architecture. That's because there are a lot of common APIs for Linux applications and because most programs are not processor dependent. This is not true of all programs, so your mileage may vary. Source packages are not that hard to make, and they provide a single package, and single file, that holds all the sources necessary to build your binary package. In addition, once you have a source RPM, it is very easy to build a binary RPM. Binary packages are likely the real reason you want to make an RPM. You can package an application, a programming library, or almost anything you want. Armed with a binary RPM, you can transfer one file to another machine and install the application there, taking full advantage of the RPM system. Gathering the software to package Whether you are writing your own software or merely packaging software found elsewhere, the next step is to gather the software you want to bundle into an RPM. This includes the applications or libraries you want to package, as well as the program source code. In general, you???ll be doing one of three things: *Packaging your own software *Packaging someone else???s software *Packaging someone else???s stuff after first customizing or patching the software In all cases, you need to gather the software together and decide whether you want everything to go into one bundle or a number of bundles. As covered in Chapter 2, a major tenet of the philosophy behind RPM is to start with pristine???unmodified--sources. You may need to patch or customize the sources for your environment, but you can always go back to the original sources. Starting with pristine sources provides a number of advantages, including the following: *You clearly separate any changes you have made to the software from the original software. *You make it easier to get an upgrade of the original sources, since your changes are cleanly separated from the original sources. With each new release of the software, you can determine which of your changes, if any, are still needed. This is especially important if you are packaging an application created by another organization into an RPM. *You have a reproducible way to recreate everything in the package. Since you start with unmodified sources, you can always go back to the beginning of the process and start again. Thus, your RPMs don???t depend on any actions taken beforehand, such as patching, that you may later forget to do because the steps are not automated as part of the RPM-building process. Start with pristine sources; then patch as needed. A patch is an automated set of modifications to the source code. Use the diff command to build a patch and the patch command to apply the patch (that is, to modify the source code). Keep the original sources separate from any patches you need to make the software work in your environment. Cross Reference See the online manual pages for the patch and diff commands for more information on how to create and apply a patch. Creating a reproducible build of the software The RPM system will automate the steps to create an application, as long as you configure the RPM with the proper steps, such as which make targets to run. Unfortunately, configuring the proper steps is not always easy. So before trying to make an RPM, you need to figure out how to build the application or library you plan to package into an RPM. Once you have figured out how to build the application or library, you can set up a reproducible build. The RPM system can then automate this build. To build the software, you???ll need to use a variety of Linux tools. The specific tools you need depend largely on where the original software came from. The following sections outline some of the more common techniques for preparing and building Linux software. Unpacking Software Many applications are downloaded in compressed tar format, often called a tarball. A tarball is merely an archive file built by the tar command that has been compressed, usually using the gzip command. In most cases, these files have a name such as the following: filename.tar.gz filename.tgz filename.tar.Z For the first two cases, use the gunzip command to unzip the file; then use the tar command to extract the file, for example: $ gunzip filename.tgz $ tar xf filename.tar Note In the case of a file name ending in .Z, use the uncompress program instead of gunzip. Once you have unpacked the sources, start looking around at the files. Reading the README Many applications come with a very handy file named README, or something similar, such as README.txt. As the name implies, you should read this file. The README file answers some of the most common questions about a particular application. Note You really should read any file named README or any variant of README. Other useful files include those named INSTALL or some close variant. Read these files, too. Usually, the README or the INSTALL file will tell you what you need to do to build the software. Once you have extracted the source code files and read all the available documentation, the next step is to build, usually compile, the application or library. Building Programs with Linux Build Tools Most applications or libraries need to be built into executable programs or compiled archived libraries. This process of building can be as simple as just compiling, but is usually more involved. Most Linux applications and libraries use a build tool called make to manage the building of the source code and creation of the executable programs. The make command uses a file, normally named Makefile, that contains the rules for building the software. You will usually find a Makefile in each directory in the source code Each Makefile contains a set of targets that define things that make can build. Each target defines the commands to run to build a particular thing (make targets are purely arbitrary, although some conventions are usually followed). Some combination of the targets results in a built application. The make program runs the targets that you specify on the command line, or the Makefile rules indicate it needs to run based on the targets you specify on the command line. You need to tell make the target to build the application or library you want to package into an RPM. Each target is defined within the Makefile. The conventional make targets to build and install a program are: make make install When you call the make command without the name of a target, make builds the default target, named all. This target usually compiles the program or library. The install target should install the program. Note The names of these make targets are conventions shared by many but not all programs. Other common targets include clean, which should clean up any files built. The commands in the Makefile may be specific to a given system. For example, the traditional command for compiling C programs is cc, short for C Compiler. You may have the gcc command (GNU C Compiler) instead. The options passed to the C compiler may differ depending on the architecture of the system. Other commands may exist but be located in different locations. SuSE Linux, for example, puts a lot of programs in /opt. Note These system-dependent issues mostly apply to various versions of Unix. Most modern Linux systems are fairly similar. Because many packages, such as sendmail, have a long UNIX history, you???ll find all sorts of complications in the Makefiles or many Makefiles provided with many applications. If we could just convince everyone to give up all non-Linux operating systems, this task would be much simpler. Because the Makefiles are platform specific, a number of tools have been developed to create the proper Makefile, usually by running a program that knows about your system's architecture. The simplest of these tools is the manual approach. You may download a program and find files such as Makefile.amiga, Makefile.solaris, and Makefile.linux. You need to copy the file for your system architecture to the name Makefile. The following sections discuss other tools for creating Makefiles. imake A program called imake is used mostly for X Window graphical applications, and typically older X Window applications. The imake command uses a file named Imakefile that contains rules used to build a platform-specific Makefile. This allows X Window applications, which run on many architectures and operating systems, to come with fairly generic build scripts. When you see an Imakefile, use the following general set of commands to compileand install an application: $ xmkmf $ make $ make install These commands work for most X Window applications. The xmkmf command is a script that runs the imake command to create a Makefile. If the xmkmf command is not available or if this command does not work, you may need to run a command such as the following: make Makefile Or, if there are multiple directories of source code, try the following command: make Makefiles Cross Reference For more on imake, see www.dubois.ws/software/imake-stuff/. The configure script Most Linux programs, especially server-side or command-line programs, use a script called configure. The configure script outputs a platform-specific Makefile. If you see a script named configure in the source files, try the following commands to build and install the program: $ ./configure $ make $ make install The ./configure command runs the script in the local directory, which outputs a Makefile configured for your system. The make command builds the program and the make install command installs the program. The configure script is created by a set of tools including automake and autoconf, which use generic files usually named configure.in and makefile.am, among other files, to create the generic configure script. In many cases, you???ll need to pass parameters to the configure script. One of the most common parameters is --prefix, which tells the configure script the name of the starting directory from which to base all other paths. This is the root directory for building the application. Cross Reference For more on the configure system, autoconf, and automake, see www.airs.com/ian/configure/. Building Perl modules Perl is a scripting language used heavily on Linux systems, especially by administrators. Most Perl modules and packages use the following set of commands to create a system-specific Makefile and to build the module: $ perl Makefile.PL $ make $ make test $ make install If you see a file named Makefile.PL, chances are these are the commands to run to build the application or module. The goal of all these steps is to figure out how to make a reproducible build of the application or library you want to package in RPM format. Once you have a build, the next step is to plan for upgrades. Planning for Upgrades Any application or library you package in RPM format is likely to get upgraded sometime. When this happens, you???ll need to make a new RPM. This new RPM must handle not only installing the package, but also handling any upgrade issues. You need to think about the following issues: *How to install the RPM for the new version of the software. Are there any necessary install scripts? *How to remove the previous RPM package. If your package has an install script, then you may need an uninstall script to cleanly remove any changes made to the system by the install script. The RPM system handles the removal of the files in the package. You need to handle the task of undoing any changes made to the system during installation. At this point in time, the main effort is to keep these issues in mind and plan ahead, since these issues will come up with any upgrade. Outlining Any Dependencies Often, the hardest task is getting make to build a program properly. One potential problem is assuring that all the dependencies are included. As you work with make, keep track of any other libraries that the program you are trying to build requires. These libraries will become dependencies when you get to the stage of making the RPM. In most cases you do not want to include the dependencies in your RPM. Instead, each dependency should have its own RPM for each necessary library. In many cases, you should be able to find RPMs for these dependencies. Keep track of the packages that provide the dependencies. After you have built the application, planned for upgrades and outlined dependencies, you can make an RPM. Building RPMs In previous chapters, just about everything you want to do with RPMs is accomplished with the rpm command. Building RPMs is one exception. Just about everything you want to do to build an RPM is done by the rpmbuild command, often with a single command. Warning Older RPM manuals refer to using the ???b option to the rpm command to create RPMs. Don???t use that option. Instead, always use the rpmbuild command. The reason for this change is that starting with version 4.1, RPM no longer maps the rpm -b command to the real command, rpmbuild. When building RPMs, go through the following steps: 1.Set up the directory structure. 2.Place the sources in the right directory. 3.Create a spec file that tells the rpmbuild command what to do. 4.Build the source and binary RPMs. The following sections provide details for these steps. Setting up the directory structure The RPM system expects five directories, as listed in Table 9-1. Table 9-1 RPM directories Directory Usage BUILD The rpmbuild command builds software in this directory. RPMS The rpmbuild command stores binary RPMs it creates in this directory. SOURCES You should put the sources for the application in this directory. SPECS You should place the spec file for each RPM you plan to make in this directory. SRPMS The rpmbuild command places source RPMs in this directory. The RPMS directory usually has a number of architecture-specific subdirectories, such as the following (on an Intel architecture system): $ ls RPMS athlon i386 i486 i586 i686 noarch By default, Red Hat Linux systems expect RPMs to be built in the /usr/src/redhat directory. Note This directory is obviously specific to Red Hat Linux. On other Linux distributions, you'll likely see other directories. Within the /usr/src/redhat directory, you???ll see the subdirectories listed in Table 9-1, as follows: $ ls /usr/src/redhat BUILD RPMS SOURCES SPECS SRPMS At first, it seems rather odd to be using a system directory to build RPMs. But remember that the RPM system was originally built to create Linux distributions. You can also change the default directories by modifying your rpmrc settings. Cross Reference See Chapter 21 for more on the use of the rpmrc settings. For now, it is easiest to just change to the /usr/src/redhat directory and work from this location. To start, you will need to change ownership or permissions on these files so you can build RPMs while logged in as a normal user. Warning Do not build RPMs while logged in as root. Mistakes in building packages can have serious consequences if you are logged in as root. To build RPMs, you really need only two things: *Your sources in the SOURCES directory *Your spec file in the SPECS directory Placing your sources into the directory structure You can place all the source files directly in the /usr/src/redhat/SOURCES directory. In most cases, however, it is easier to create a tarball of the sources you want to build and place the tarball file in the /usr/src/redhat/SOURCES directory. The RPM specifications for commands necessary to extract the sources from such a file are trivial. Furthermore, the tarball, when extracted, should create a subdirectory specific to your package. This keeps your source code separate from other packages that also have source code in the SOURCES directory. The best strategy is to start in a directory of your own making, create the tarball file from the sources, and then copy the tarball file to the /usr/src/redhat/SOURCES directory. The convention for these tarball files is package-version.tar.gz. For example: jikes-1.17.tar.gz Place a file like this into the /usr/src/redhat/SOURCES directory. This file should include all the sources, all the build scripts, and any documentation you want to install as part of the package. Creating the spec file The spec file, short for specification file, defines all the actions the rpmbuild command should take to build your application, as well as all the actions necessary for the rpm command to install and remove the application. Each source RPM should have the necessary spec file for building a binary RPM. The spec file is a text file. The normal naming convention is to name the file with the package name and a .spec filename extension. For example, the jikes package spec file would be named jikes.spec. Inside the spec file, format the information on the package using a special syntax. This syntax defines how to build the package, version numbers, dependency information, and everything else you can query about a package. This syntax differs slightly depending on the sections in the spec file. The following sections describe these spec file sections and the necessary syntax in each section. The introduction section The introduction section contains information about the package, the type of information shown with the rpm -qi command. For example: Summary: java source to bytecode compiler %define version 1.17 Copyright: IBM Public License, http://ibm.com/developerworks/oss/license10.html Group: Development/Languages Name: jikes Prefix: /usr Provides: jikes Release: 1 Source: jikes-%{version}.tar.gz URL: http://ibm.com/developerworks/opensource/jikes Version: %{version} Buildroot: /tmp/jikesrpm %description The IBM Jikes compiler translates Java source files to bytecode. It also supports incremental compilation and automatic makefile generation, and is maintained by the Jikes Project: http://ibm.com/developerworks/opensource/jikes/ In this example, you can see the Source: definition of a compressed tar archive associated with a particular version number. This also names a Buildroot: setting that defines where the files will get built into a working program. You can see the description of the package that will get printed with the rpm ???qi command. Note You can further divide this first section into the preamble and other areas. For simplicity, I grouped all introductary parts of a spec file into one introduction section. This example comes from a real-world RPM spec file. It does not follow all the rules for creating RPMs. This example: *Should not explicitly provide jikes, the name of the package. *Should not include a Copyright tag, as this tag is deprecated. *Uses a %define for the version when the rpmbuild command can create a version macro for you. The prep section The prep section, short for prepare, defines the commands necessary to prepare for the build. If you are starting with a compressed tar archive (a tarball) of the sources, the prep section needs to extract the sources. For example: %prep %setup -q The prep section starts with a %prep statement. This example uses the %setup RPM macro, which knows about tar archives, to extract the files. In most cases, this will be all you need in your spec file prep section. The build section The spec file build section contains the commands to build the software. Usually, this will include just a few commands, since most of the real instructions appear in the Makefile. For example: %build ./configure CXXFLAGS=-O3 --prefix=$RPM_BUILD_ROOT/usr make The build section starts with a %build statement. The commands shown for this build section run the configure script, covered in the previous section on Linux build tools, and then run the make command with the default maketarget. If things unfold as they should, this procedure builds the software. The install section The spec file install section holds the commands necessary to install the newly built application or library. In most cases, your install section should clean out the Buildroot directory and run the make install command. For example: %install rm -fr $RPM_BUILD_ROOT make install The install section starts with an %install statement. The clean section The clean section cleans up the files that the commands in the other sections create: %clean rm -rf $RPM_BUILD_ROOT The clean section starts with a %clean statement The files section Finally, the files section lists the files to go into the binary RPM, along with the defined file attributes. For example: %files %defattr(-,root,root) /usr/bin/jikes %doc /usr/doc/jikes-%{version}/license.htm %doc /usr/man/man1/jikes.1* The files section starts with a %files statement The %doc macro marks certain files as documentation. This allows the RPM to distinguish the files holding documentation from the other files in the RPM. Cross Reference This example skips the install and uninstall script sections, as well as a verification section. There are also no triggers defined in this RPM spec file. All of these topics are covered in Chapters 10 and 11. Once you have written your spec file, and placed the files in the SOURCES and SPECS directories under /usr/src/redhat, you???ll see files like the following: $ ls ???CF /usr/src/redhat/* /usr/src/redhat/BUILD: /usr/src/redhat/RPMS: athlon/ i386/ i486/ i586/ i686/ noarch/ /usr/src/redhat/SOURCES: jikes-1.17.tar.gz /usr/src/redhat/SPECS: jikes.spec /usr/src/redhat/SRPMS: That is, with a clean system and no other RPMs being built, you'll see a spec file in /usr/src/redhat/SPECS and the sources in /usr/src/redhat/SOURCES. In this example, the sources are in a compressed tar archive. (For this, the RPM spec file, jikes.spec needs to have a command in the prep section to extract the files.) You should now be ready to build an RPM. Building RPMs with the rpmbuild command To build RPMs with the rpmbuild command, use the following basic syntax: rpmbuild -bBuildStage spec_file The -b option tells rpmbuild to build an RPM. The extra BuildStage option is a special code that tells the rpmbuild command how far to go when building. Table 9-2 lists these options: Table 9-2 Options for building with rpmbuild Option Usage -ba Build all, both a binary and source RPM -bb Build a binary RPM -bc Build (compile) the program but do not make the full RPM, stopping just after the %build section -bp Prepare for building a binary RPM, and stop just after the %prep section -bi Create a binary RPM and stop just after the %install section -bl Check the listing of files for the RPM and generate errors if the buildroot is missing any of the files to be installed -bs Build a source RPM only Note See chapter 12 for advanced options you can use with rpmbuild. For example, to set up all the necessary files and prepare for building, run the following command: rpmbuild ???bp specfile This example runs through the %prep section, and stops immediately after this section. With the jikes package, for example, you???ll see a result like the following: $ rpmbuild -bp /usr/src/redhat/SPECS/jikes.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.72435 + umask 022 + cd /usr/src/redhat/BUILD + LANG=C + export LANG + cd /usr/src/redhat/BUILD + rm -rf jikes-1.17 + /usr/bin/gzip -dc /usr/src/redhat/SOURCES/jikes-1.17.tar.gz + tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd jikes-1.17 ++ /usr/bin/id -u + '[' 500 = 0 ']' ++ /usr/bin/id -u + '[' 500 = 0 ']' + /bin/chmod -Rf a+rX,g-w,o-w . + exit 0 After running this command, the source files are extracted into the /usr/src/redhat/BUILD directory, under the jikes-1.17 subdirectory. Using a subdirectory keeps the sources for this package from intermixing with the sources for other packages. Running a directory listing on the /usr/src/redhat/BUILD/jikes-1.17 subdirectory shows what the spec file %prep section commands have done. For example: $ ls -1 /usr/src/redhat/BUILD/jikes-1.17 acinclude.m4 aclocal.m4 AUTHORS ChangeLog config.guess config.sub configure configure.in COPYING depcomp doc INSTALL install-sh jikes.spec Makefile.am Makefile.in missing mkinstalldirs NEWS README src TODO Note From these sources, you see a configure script. The configure script gives a good indication of how the software needs to be built. This example also shows a README file. You know what to do with these files. The actual source code is in the /usr/src/redhat/BUILD/jikes-1.17/src directory. The user documentation is stored in the /usr/src/redhat/BUILD/jikes-1.17/doc directory. To build a binary RPM, use the ???bb option to the rpmbuild command. For example: $ rpmbuild -bb /usr/src/redhat/SPECS/jikes.spec Warning Don???t build packages when you are logged in as the root user. Log in as a normal user instead. This is to limit the damage caused to your system if the spec file or the Makefile contains errors that delete system files, for example. If you are logged in as the root user, you will have permission to perform these destructive acts. If you are logged in as a normal user, though, these RPM spec file and Makefile errors will fail to run, because you don???t have permission to modify system files. This command results in a lot of output, most coming from the configure script. (This script examines the C programming environment on your system.) When the rpmbuild command completes, you???ll see the binary RPM in the proper subdirectory of the RPMS directory. You can see the RPM with a directory listing, for example: $ls /usr/src/redhat/RPMS/i386: jikes-1.17-1.i386.rpm To stop execution just after the %install section, use a command like the following: rpmbuild ???bi specfile For example: # rpmbuild -bi /usr/src/redhat/SPECS/jikes.spec To build a source RPM out of the files you have (in this case a tar archive of the sources and the spec file), use a command like the following: rpmbuild ???bs specfile For example: $ rpmbuild -bs /usr/src/redhat/SPECS/jikes.spec When done, you???ll see the source RPM in the /usr/src/redhat/SRPMS directory: $ ls /usr/src/redhat/SRPMS jikes-1.17-1.src.rpm To clean out the files created by building these RPMs, use the --clean option to the rpmbuild command: rpmbuild --clean specfile For example: $ rpmbuild --clean /usr/src/redhat/SPECS/jikes.spec Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.21908 + umask 022 + cd /usr/src/redhat/BUILD + rm -rf jikes-1.17 + exit 0 Cross Reference Chapter 12 covers a number of addition options for the rpmbuild command that you can use to customize the build. Verifying Your RPMS After you've built an RPM, you can use the techniques from Chapter 5 to verify the RPM. You can also use the ???bl option to the rpmbuild command to verify the list of files in the RPM. Use a command like the following: rpmbuild ???bl spec_file For example: $ rpmbuild -bl /usr/src/redhat/SPECS/jikes.spec Processing files: jikes-1.17-1 error: File not found: /tmp/jikesrpm/usr/bin/jikes error: File not found: /tmp/jikesrpm/usr/doc/jikes-1.17/license.htm error: File not found by glob: /tmp/jikesrpm/usr/man/man1/jikes.1* Provides: jikes RPM build errors: File not found: /tmp/jikesrpm/usr/bin/jikes File not found: /tmp/jikesrpm/usr/doc/jikes-1.17/license.htm File not found by glob: /tmp/jikesrpm/usr/man/man1/jikes.1* This example shows a number of errors. The -bl option checks that all the necessary files are located within the buildroot directory. The buildroot directory is a location that acts like the final installed root directory. From the previous example, this package was not properly built yet. In a situation like this, you can start over, or use the --short-circuit option to restart the build from a given section in the spec file. As you create an RPM, you will need to go back and forth restarting the build as you detect and fix errors. You can also use the rpm command with options such as ???V for verification on a fully-built package. For example: $ rpm -Vp /usr/src/redhat/RPMS/i386/jikes-1.17-1.i386.rpm S.5....T /usr/bin/jikes .......T d /usr/doc/jikes-1.17/license.htm ..5....T d /usr/man/man1/jikes.1.gz In this case, you see some file sizes and times differ. These differences can be explained by the fact that the original package was compiled on a different system and older version of Red Hat Linux than the version compiled locally. Cross Reference See the on "Verifying Installed RPM Packages" section in Chapter 5 for more on the -V option. Summary This chapter introduced the task of building RPMs, whether building RPMs from your own applications or from software you have gathered elsewhere. In both cases, the steps for building the RPMs are the same. In most cases, you should build an RPM of the sources for your application, an RPM that can be used to reproduce the build of the application. Create a second RPM that holds the binary application. Once you set up the commands and define the spec file for the binary RPM, making a source RPM is trivial. Use the rpmbuild command to create RPMs. This command uses an RPM spec file to define the commands and settings for creating the RPM. The next chapter delves into the spec files that define the RPM directives for your packages. From fedora-docs-commits at redhat.com Tue Oct 4 01:48:59 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:48:59 -0400 Subject: rpm-guide rpm-guide-customizing-rpm-en.xml,NONE,1.1 Message-ID: <200510040148.j941mxa1000452@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv434 Added Files: rpm-guide-customizing-rpm-en.xml Log Message: --- NEW FILE rpm-guide-customizing-rpm-en.xml --- Customizing RPM Behavior Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Chapter *Defining RPM macros *Configuring RPM settings *Adding popt aliases RPM provides a high degree of customization in the form of basic settings, such as where your RPM database is located and the path to common commands like setup or make, to the ability to define new macros and command-line aliases. This chapter covers the three main ways to customize RPM behavior: RPM macros, RPM rc settings, and popt aliases. Customizing with RPM Macros Starting with RPM 3.0, RPM macros have replaced most RPM settings from the rpmrc files. An RPM macro defines a setting to the RPM system. A macro can be defined as a static value, such as the directory where the RPM database is installed. A macro can also be defined in terms of other macros. Furthermore, a macro can be defined with parameters. For example, the following defines two macros in a macro file: %_usr /usr %_usrsrc %{_usr}/src In this case, the macro %_usr names the /usr directory. The macro %_usrsrc names the /usr/src directory, showing how to set a macro in terms of another macro. Cross Reference The macro syntax is used in the query formats introduced in Chapter 5. Defining macros RPM provides a number of places you can define macros, including inside spec files (probably the most common usage), in special macro initialization files, and on the command line. In each case, the syntax is slightly different. Defining Macros in Spec Files You can define macros in most places in a spec file. With spec files, use the %define syntax to define a macro, which uses the following syntax: %define name(options) body The options are optional and can include the special values defined in Table 21-1. Table 21-1 Special options for macros Option Holds %0 The name of the macro %1 The first argument, after processing with getopt %2-%9 Additional arguments %* All arguments, except for flags that have been processed %# Number of arguments These options are similar to those for shell scripting. Cross Reference Chapter 10 covers spec files. In addition to these options, you can use a syntax of %{-a} to hold ???a if an option of ???a was passed. The syntax of %{-a*} indicates the value passed after the ???a option. You can assign a macro to the value returned by a shell command by using syntax like the following: %(shell_command) Note This is similar to the $(shell_command) syntax supported by bash. Defining Macros in Macro Initialization Files Inside a macro file, define macros with the following syntax: %macro_name value Macros defined for the RPM system start with an underscore. Some older macros are left without the leading underscore. Note The macros defined with an underscore are not exported into rpm headers. The %expand built-in macro will expand the value of something else, including executing a shell command. For example, the following sets the user???s home directory to the %home macro: %home %{expand:%%(cd; pwd)} Note that it is probably easier to simply set the %home macro in your per-user $HOME/.rpmmacros file to the name of your home directory rather than try to figure this out programmatically. Defining Macros on the Command Line The rpm command also lets you define macros with the --define option. The basic syntax is: $ rpm --define 'macro_name value' Note Do not place the leading percent sign, %, on the macro you define with --define. You can evaluate a macro or a macro expression with --eval. For example: $ rpm --eval %_usrsrc /usr/src Customizing Macros You can add your own macro definitions, using the syntax shown in the ???Defining Macros in Macro Initialization Files??? section. These macros are read on each invocation of the rpm or rpmbuild commands. To add your custom macros, you must edit one of the macro definition files. Table 21-2 lists the macro definition files and their usage. Table 21-2 RPM macro files File Usage /usr/lib/rpm/macros Official RPM macros /etc/rpm/macros Per-system customizations $HOME/.rpmmacros Per-user customizations Note Do not edit the /usr/lib/rpm/macros file, as this file gets overwritten when you upgrade to a new version of rpm. Configuring RPM Settings RPM includes hundreds of settings based on your current system architecture, environment, and which version of the RPM system you have installed. The old settings, called rc or rpmrc settings, are gradually being phased out by the newer, more consistent and more powerful macros. You can still edit the rc settings, but in most cases you should edit macros instead. Viewing the current settings To view the current settings, use the --showrc command-line option: $ rpm ???showrc ARCHITECTURE AND OS: build arch : i386 compatible build archs: i686 i586 i486 i386 noarch build os : Linux compatible build os's : Linux install arch : i686 install os : Linux compatible archs : i686 i586 i486 i386 noarch compatible os's : Linux RPMRC VALUES: macrofiles : /usr/lib/rpm/macros:/usr/lib/rpm/i686-linux/macros:/etc/ rpm/macros.specspo:/etc/rpm/macros.db1:/etc/rpm/macros.cdb:/etc/rpm/macros:/etc/ rpm/i686-linux/macros:~/.rpmmacros optflags : -O2 -march=i686 This command displays the architecture and operating system information first, and then lists all the rpmrc values, shown here truncated for space. Locating the rpmrc files The --showrc option reads in all the rpmrc files from the various locations. By default, this is /usr/lib/rpm/rpmrc, /etc/rpm/rpmrc, and a file named .rpmrc (with a leading period) in your home directory. These files are read in the order given, so that the later files can override settings in the earlier files. The uses for these files are listed in Table 21-3. Table 21-3 Uses for the rpmrc files File Holds /usr/lib/rpm/rpmrc RPM standard settings /etc/rpm/rpmrc Per-system configuration $HOME/.rpmrc Per-user configuration Note The file /usr/lib/rpm/rpmrc gets overwritten each time you upgrade RPM. Do not customize this file. You can override this list of files by calling the rpm or rpmbuild commands with the --rcfile option. This option expects a semicolon at nddelimited list of files to read in, in order. For example, if you are working on a 686-architecture Intel platform, you can create a file with the following setting: optflags: i686 -g Note that this disables optimization, so it is not a good setting. (The use of this value will make the result more visible.) If you name this file .rpmnew and place it in your home directory, you can configure an alternate set of files with the --rcfile option and then evaluate the new optflags setting. For example: $ rpm --eval "%{optflags}" -O2 -march=i386 -mcpu=i686 $ rpm --rcfile $HOME/.rpmnew --eval "%{optflags}" -g This example shows the value before and after changing the configuration files. When you use the --rcfile option, only the first file listed must exist. The rest of the files are optional. When you use the --rcfile option, however, the file /usr/lib/rpm/rpmrc is read first, and then the list of files you provide with the --rcfile option. The file /usr/lib/rpm/rpmrc is always used. Changing settings You can edit the per-user or per-system rc files to change the settings. The format of the rpmrc files is fairly simple but contains a few exceptions. The most basic format is: setting: value The settings get more complicated as the rpmrc syntax supports defining settings for multiple architectures at once. In that case, the typical format is: setting: uname: value The uname portion is replaced by a value that comes from the uname(2) system call, for example, i686 on a 686-class Intel architecture machine. Note In most cases, your best bet is to copy an existing setting and modify it, rather than remembering all the exceptions. Setting the optflags One exception to the rule is the optflags setting, which controls C compiler options for optimization. The format for the optflags setting is: setting: arch value There is no colon after the architecture. For example: optflags: i686 -O2 -march=i686 optflags: alphaev5 -O2 -mieee -mcpu=ev5 This example sets the optimization flags for an i686 system to -O2 -march=i686 and an alphaev5 system to -O2 -mieee -mcpu=ev5. If your system is running on a 686-class processor, you will get one set of optimization flags. If your system is running on a V5 Alpha processor, you will get a different set. Setting the Architecture Values The arch_canon setting builds up a table of mappings between architecture names and the numbers used internally. The following example shows the Intel and SPARC architecture settings to 1 and 3 internally. arch_canon: athlon: athlon 1 arch_canon: i686: i686 1 arch_canon: i586: i586 1 arch_canon: i486: i486 1 arch_canon: i386: i386 1 arch_canon: sparc: sparc 3 arch_canon: sun4: sparc 3 arch_canon: sun4m: sparc 3 arch_canon: sun4c: sparc 3 arch_canon: sun4d: sparc 3 arch_canon: sparcv9: sparcv9 3 The arch_compat setting builds a table of compatible architectures. The format is: arch_compat: arch: compatible_with This sets the given architecture arch as being compatible with another architecture. For example: arch_compat: athlon: i686 This setting indicates that an athlon architecture is compatible with an i686. The table gets built up further with the following Intel-architecture compatibilities: arch_compat: i686: i586 arch_compat: i586: i486 arch_compat: i486: i386 arch_compat: i386: noarch The os_canon setting defines a table of operating system labels and internal numeric values. The basic syntax is: os_canon: arch: name value The arch comes from the uname(2) call. The name provides an RPM name for that operating system, and the value defines an internal numeric ID for that OS, for example: os_canon: Linux: Linux 1 os_canon: HP-UX: hpux10 6 The buildarchtranslate setting defines the operating system settings to use as the build architecture. This value translates information from the uname(2) call to a value used by the arch_canon setting. For example: buildarchtranslate: athlon: i386 buildarchtranslate: i686: i386 buildarchtranslate: i586: i386 buildarchtranslate: i486: i386 buildarchtranslate: i386: i386 buildarchtranslate: sun4c: sparc buildarchtranslate: sun4d: sparc buildarchtranslate: sun4m: sparc buildarchtranslate: sparcv9: sparc buildarchtranslate: sun4u: sparc64 Adding Popt Aliases Popt provides a powerful library and RPM subsystem for handling the very complex RPM command-line options. You can customize your RPM usage by defining popt aliases for complex command-line arguments to the rpm or rpmbuild commands. A popt alias is a command-line option that expands to other command-line options. This technique is used internally to define quite a few command-line options to the rpm and rpmbuild commands in terms of other, more complex options. Many of these aliases define simple command-line options in place of more complex query format options. Cross Reference Chapter 5 covers the query format. For example, the following entry defines the --requires and ???R command-line options to the rpm command: rpm alias --requires --qf \ "[%{REQUIRENAME} %{REQUIREFLAGS:depflags} %{REQUIREVERSION}\n]" \ --POPTdesc=$"list capabilities required by package(s)" rpm alias -R --requires These options are set in the file /usr/lib/rpm/rpmpopt-4.1. Note This is specific to RPM 4.1. Other releases of RPM use the same naming format but with the current RPM version number, such as 4.2 and so on. Defining aliases Defining aliases is pretty easy. The basic syntax is: command_name alias option expansion To create an alias for the rpm command, you use rpm for the command_name. Note The command_name must be the name passed to the C poptGetContext function, covered in Chapter 16. Follow this with alias and then the option. You will need separate aliases for the long and short options. The expansion defines the alias in terms of other already-defined command-line parameters. You can define some complex aliases, such as the following one to display information about a package: rpm alias --info --qf 'Name : %-27{NAME} Relocations: %|PREFIXES?{[%{PREFIXES} ]}:{(not relocateable)}|\n\ Version : %-27{VERSION} Vendor: %{VENDOR}\n\ Release : %-27{RELEASE} Build Date: %{BUILDTIME:date}\n\ Install date: %|INSTALLTIME?{%-27{INSTALLTIME:date}}:{(not installed) }| Build Host: %{BUILDHOST}\n\ Group : %-27{GROUP} Source RPM: %{SOURCERPM}\n\ Size : %-27{SIZE}%|LICENSE?{ License: %{LICENSE}}|\n\ Signature : %|DSAHEADER?{%{DSAHEADER:pgpsig}}:{%|RSAHEADER?{%{RSAHEADER:pgpsig}}:{%|SIGGPG?{%{SIGGPG:pgpsig}}:{%|SIGPGP?{%{SIGPGP:pgpsig}}:{(none)}|}|}|}|\n\ %|PACKAGER?{Packager : %{PACKAGER}\n}|\ %|URL?{URL : %{URL}\n}|\ Summary : %{SUMMARY}\n\ Description :\n%{DESCRIPTION}\n' \ --POPTdesc=$"list descriptive information from package(s)" Popt aliases get evaluated into Linux commands, so you can use pipes and other aspects of Linux shells in your aliases. Cross Reference Look closely at the examples in the /usr/lib/rpm/rpmpopt-4.1 file. This is the most complete set of popt alias examples for RPM commands. You can also define aliases that can set RPM macros, such as the following alias for setting the path to the RPM database: rpm alias --dbpath --define '_dbpath !#:+' In this example, !#:+ was defined to behave like a shell history-editing command. With popt, this means to grab the next command-line parameter and place it into the command defined for the alias. To support the --help and --usage options, you can define the --POPTdesc and --POPTargs options to the alias as shown in the previous examples. These options also support internationalization. All together, the popt alias setting is very close to the popt option table entries used with the C programming API. Cross Reference Chapter 16 shows how to program with the popt library. Customizing popt aliases Like RPM macros and settings, popt aliases are defined in a cascading set of files. The official RPM aliases are defined in /usr/lib/rpm/rpmpopt-4.1 for rpm 4.1. Note Do not modify this file! The RPM system depends on this file for proper functioning. Incorrect changes might disable many options to the rpm command. Store per-system popt aliases in /etc/popt. Store per-user aliases in $HOME/.popt (with a leading period). Note These files are shared by all applications that use popt. For example, you can define an alias for rpm -qa that executes faster than the normal query all packages command, by turning off the tests for digest signature verification. To do so, add the following line to a file named .popt in your home directory: rpm alias --qall -qa --nodigest --nosignature Once you set up this alias, you can run the following command in place of rpm -qa: $ rpm --qall This should execute about one-third to one-half faster than the normal rpm -qa command. Warning Turning off the signature and digest tests means you are ignoring important information that pertains to the integrity of your system. That is why the alias shown here does not override the normal -qa option, and instead defines a new --qall option Summary This chapter shows the many ways you can customize RPM usage for your system or your own personal environment. You can define RPM macros, which is the preferred way to make RPM settings. Or you can set RPM values in the older rpmrc files, which are now mostly replaced by RPM macros. Using popt, the powerful command-line option parser, you can define aliases to add simple options that popt expands into whatever you define. Many of the rpm command-line options are defined this way. From fedora-docs-commits at redhat.com Tue Oct 4 01:49:43 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:49:43 -0400 Subject: rpm-guide rpm-guide-dependencies-en.xml,NONE,1.1 Message-ID: <200510040149.j941nhvE000481@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv463 Added Files: rpm-guide-dependencies-en.xml Log Message: --- NEW FILE rpm-guide-dependencies-en.xml --- Package Dependencies In This Chapter *Understanding dependencies *Package capabilities *Version dependencies *Checking dependencies *Triggers Packages aren???t built in a vacuum. Web applications, for example, build on system networking libraries, system-encryption libraries, and system-file input and output libraries. This chapter covers dependencies between packages, along with ways to discover and manage those dependencies. Understanding the Dependency Concept A dependency occurs when one package depends on another. You might think it would make for an easier-to-manage system if no package depended on any others, but you???d face a few problems, not the least of which would be dramatically increased disk usage. Packages on your Linux system depend on other packages. Just about every package with an application, for example, depends on the system C libraries, since these libraries provide common facilities that just about every program uses. Network applications typically depend on low-level networking libraries. These dependencies really work in your favor, since a security bug fix in the network libraries can update all applications that make use of the updated libraries. Furthermore, sharing software means that each package has less code to maintain and thus improved quality. Code sharing has been in the computer lexicon since the 1960s. Although quite a few packages depend on system-level libraries, some packages depend on applications defined in other packages. The Emacs text editor package, for example, depends on the Perl scripting language, specifically, the perl command. Database client programs usually depend on the database server applications. The RPM database tracks dependency information, so it can, for example, stop attempts to remove packages that other packages depend on or inform users of dependent packages upon installation. Capabilities In RPM terminology, each package provides capabilities. A capability is simply a text string that the package claims it provides. In most cases, a capability names a file or a package. But the capability can be any arbitrary text string. Other packages can then depend on certain capabilities. (You can use this concept in building your own packages.) Each package lists the capabilities it requires as well as the capabilities it provides. Cross Reference Package dependencies and capabilities are very important when creating spec files for building your own RPM packages, the subject of Chapter 10. When you install a package, the capability information is stored in the RPM database. When you remove a package, the rpm command checks the RPM database. If the package you are trying to remove provides a capability that another package needs, the command will generate an error. If you try to remove a package that other packages depend on, you'll see an error like the following: # rpm -e setup error: Failed dependencies: setup is needed by (installed) basesystem-8.0-1 setup >= 2.0.3 is needed by (installed) initscripts-6.95-1 setup >= 2.5.4-1 is needed by (installed) filesystem-2.1.6-5 setup is needed by (installed) xinetd-2.3.7-2 setup is needed by (installed) dump-0.4b28-4 To verify that the package has not been removed, you can query for the package after trying to remove it, as shown following: # rpm -q setup setup-2.5.20-1 This shows that the rpm command has not removed the setup package due to the errors. Cross Reference Chapter 4 covers ways to force the rpm command to do what you want, although this can cause problems if you try to force the issue and remove a crucial package. In virtually all cases, do not use any of the force options, as this can cause problems with the RPM system, since the force options are purposely ignoring safety checks performed by the rpm command. Many capabilities that packages require are system libraries, especially shared libraries. Shared libraries, which usually have a .so file extension (short for shared object), provide a memory-efficient means for applications to share program code. These libraries may also have a .so.number extension, such as libc.so.6. Note Shared libraries on Windows are called DLLs, short for Dynamic Link Libraries. The implementations differ, but the Windows DLL concept is similar to Linux and Unix shared objects. Shared libraries have been part of Linux for a long time and have nothing to do with the RPM system. Shared libraries accessed by a program, however, represent natural dependencies. Because so many programs depend on shared libraries, the RPM system can automatically handle many shared-library dependencies. Note To list the shared libraries that a program accesses, use the ldd command, for example: $ ldd /bin/grep libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Other dependencies include version-specific dependencies. Version dependencies An application may depend on a capability provided by another package. It may also depend on the capability that a specific version of another package provides. For example, some add-ons to the Apache Web server depend on the version of Apache. The Apache 2.0 version made a number of changes that affect add-on packages. Some Apache add-on packages depend on version 1.3; others depend on version 2.0. Most package dependencies assume some level of compatibility and require a version at or above a given version number (for example, version 2.0 or later). Note You???ll see more version dependencies when applications make major changes, such as the change from 1.3 to 2.0 for the Apache Web server. Conflicts Some packages may provide capabilities that interfere with those in other packages. This is called a conflict. Installing conflicting packages is an error. For example, the httpd package (the Apache Web server) conflicts with the thttpd package. Both packages want to provide the primary Web server for a system. The RPM system will prevent you from installing packages that conflict with other packages. You can force the issue, using the techniques described in Chapter 4, and override the RPM system. But in most cases, you should not install packages that conflict. Obsoletes The RPM system supports one more type of dependency, called obsoletes. This refers to a capability that a package provides that makes another capability obsolete. For example, a new version of the perl interpreter may make an older version obsolete. In most cases, the obsoletes dependency should be used when the name of a package changes. For example, the apache Web server package became the httpd package. You would expect the new package, httpd, to obsolete the old package name, apache. This brings the total to four types of dependencies that the RPM system tracks: *Requires, which tracks the capabilities a package requires *Provides, which tracks the capabilities a package provides for other packages *Conflicts, which describes the capabilities that if installed, conflict with capabilities in a package *Obsoletes, which describes the capabilities that this package will make obsolete Packages advertise this dependency information. Each dependency holds the type, such as requires, a capability, such as a shared library or a package name, and optionally a version number, such as requiring the python package at a version number greater than or equal to 2.2 (python >= 2.2). You can check package dependencies by using, as you???d guess, the rpm command. Checking for Dependencies The rpm ???q command queries the RPM database or RPM package files. With the right options to this command, you can check for the four types of package dependencies as well. These options are based on the concept of capabilities introduced previously. You can query what capabilities a package requires. You can also query what capabilities a package provides. You can query for the obsoleting and conflicting information as well. Furthermore, given a capability, you can query which packages require this capability as well as which packages provide this capability. Cross Reference There are quite a few more options you can use with the rpm ???q command for querying packages. See Chapter 5 for more on querying packages and package files. Determining the capabilities a package requires The first and most important step is to determine what capabilities a package requires. If all the required capabilities are met, you can safely install the package (barring other things that can go wrong, such as conflicts). The requires dependencies are by far the most important. The --requires option to the rpm ???q command lists the capabilities a given package requires. The basic syntax is: rpm ???q query_options --requires packages For example: $ rpm -qp --requires sendmail-8.12.5-7.i386.rpm /usr/sbin/alternatives rpmlib(VersionedDependencies) <= 3.0.3-1 chkconfig >= 1.3 /usr/sbin/useradd /bin/mktemp fileutils gawk sed sh-utils procmail bash >= 2.0 /bin/sh /bin/sh /bin/sh /bin/sh /bin/sh rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 /bin/bash libcrypto.so.2 libcrypt.so.1 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.2) libdb-4.0.so libgdbm.so.2 libhesiod.so.0 liblber.so.2 libldap.so.2 libnsl.so.1 libnsl.so.1(GLIBC_2.0) libresolv.so.2 libresolv.so.2(GLIBC_2.0) libresolv.so.2(GLIBC_2.2) libsasl.so.7 libssl.so.2 This example tests an RPM package file, sendmail-8.12.5-7.i386.rpm, for the requires dependency, in other words, what capabilities the package requires. The sendmail package depends on a lot of other parts of the system, as you can see in the response to the command shown previously. Most of the dependencies are for system libraries (all the dependencies ending in .so or .so.number). This package requires other capabilities (packages in this case). It also requires the chkconfig package at a specific version, version 1.3 or higher, and the bash package at version 2.0 or higher. The sendmail package also requires a particular version of the RPM system (the rpmlib dependency). Warning Always check what a package requires before installing the package. You can also use the --test option when trying to install the package to first test whether the installation can proceed. See Chapter 4 for details on installing packages and the --test option. The rpm command will perform all these checks for you anyway. Checking in advance, though, with the --test option, helps avoid dependency hell with circular dependencies. You can also check for what an installed package requires with the --requires option. For example: rpm -q --requires sendmail You can use the -R short option in place of the --requires option. This command returns the same data as the previous command but queries an installed package rather than an RPM package file. You might assume that applications have the most dependencies, which is true. But even source packages may depend on other packages, often the packages needed to build the sources into an application. For example, the following command lists the capabilities required by a source RPM: $ rpm -qp --requires telnet-0.17-23.src.rpm ncurses-devel Some packages require particular versions of other packages, for example: rpm -qp --requires xcdroast-0.98a9-18.src.rpm imlib-devel >= 1.9.13-9 gtk+-devel >= 1.2.10 desktop-file-utils >= 0.2.92 rpmlib(CompressedFileNames) <= 3.0.4-1 This example shows that the xcdroast source package requires the imlib-devel capability (in this case, a package) at version 1.9.13-9 or higher, the gtk+-devel package at version 1.2.10 or higher, and the desktop-file-utils package at version 0.2.92 or higher. This is a more stringent requirement than just depending on the given packages being installed. This RPM is also an older RPM package, based on the requirement for the rpmlib to be prior or equal to 3.0.4-1. Some packages may require a particular version of the rpmlib, or RPM library. For example, the setup package contains special system configuration files, including the default password file, /etc/passwd. $ rpm -q --requires setup rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 As shown in this example, this package depends only on capabilities of the RPM system itself. The particular requirements shown here specify how the rpm command should treat the package payload, including how the files are listed in the package and what type of compression is used. Determining the capabilities a package provides Packages require capabilities, and they can provide capabilities for other packages to require. To list the capabilities a package provides, use the --provides option. These capabilities can be arbitrary names, shared libraries (.so files), and the package name itself. The basic syntax is: rpm ???q query_options --provides packages For example, the tcsh shell package provides two capabilities, at a particular version number, as shown following: $ rpm -q --provides tcsh csh = 6.12 tcsh = 6.12-2 Other packages provide a lot more, including shared libraries. The httpd package provides a long list of capabilities, as shown following: $ rpm -q --provides httpd webserver httpd-mmn = 20020628 libapr.so.0 libaprutil.so.0 mod_access.so mod_actions.so mod_alias.so mod_asis.so mod_auth_anon.so mod_auth_dbm.so mod_auth_digest.so mod_auth.so mod_autoindex.so mod_cern_meta.so mod_cgi.so mod_dav_fs.so mod_dav.so mod_deflate.so mod_dir.so mod_env.so mod_expires.so mod_headers.so mod_imap.so mod_include.so mod_info.so mod_log_config.so mod_mime_magic.so mod_mime.so mod_negotiation.so mod_proxy_connect.so mod_proxy_ftp.so mod_proxy_http.so mod_proxy.so mod_rewrite.so mod_setenvif.so mod_speling.so mod_status.so mod_suexec.so mod_unique_id.so mod_userdir.so mod_usertrack.so mod_vhost_alias.so httpd = 2.0.40-8 Checking for conflicts Use the --conflicts option to check what conflicts with a given package. The basic syntax is: rpm ???q query_options --conflicts packages For example: # rpm -q --conflicts httpd thttpd This command tells you that the httpd package (the Apache Web server) conflicts with the thttpd package. Both packages provide a similar capability. By marking the conflict, the httpd package tells you that you cannot normally install both the httpd and thttpd packages on a system. This information comes from the httpd package, which has an entry in the package that indicates the conflict. The conflict is not guaranteed. These packages may work together, but the creator of the httpd package felt that httpd would not work with the thttpd package and helpfully let us all know. The RPM system will report on the conflicts and indicate an error if you try to install conflicting packages. The idea of conflicts really gives package creators a way to alert users to potential problems and to tell us that one package likely won???t work with another. The force options discussed in Chapter 4 allow you to override conflicts, if absolutely necessary. In most cases, though, a conflict presents you with the choice to install one or the other of the packages, but not both. Determining which packages require a certain capability In addition to querying capabilities and requirements of a particular package, you can query the capabilities themselves. This function allows you to check which packages require a given capability. The --whatrequires option tells the rpm command to report on which packages in the RPM database require a certain capability. The basic syntax is: rpm ???q query_options --whatrequires capability Some packages are not required by anything: $ rpm -q --whatrequires tcsh no package requires tcsh Note Don???t worry about the poor tcsh package being lonely. Because other packages do not require this package, you can easily remove the tcsh package without affecting the rest of your system. This example shows a package name as the capability. Shared libraries are also considered capabilities. You can query on these as well. For example: $ rpm -q --whatrequires librpm-4.1.so rpm-4.1-1.06 net-snmp-5.0.1-6 rpm-python-4.1-1.06 rpm-devel-4.1-1.06 rpm-build-4.1-1.06 This example shows that the core RPM library is used by a number of RPM-related packages, along with, oddly enough, the net-snmp system-management package. The capability you query for must be an explicit capability. For example, you will get different results if you query for the bash package or the command, /bin/bash. If you query for the bash package, you will see the packages that explicitly require the capability bash. For example: $ rpm -q --whatrequires bash gpm-1.19.3-20 info-4.0b-3 initscripts-6.40-1 sendmail-8.11.6-3 sysklogd-1.4.1-4 vixie-cron-3.0.1-63 ypbind-1.8-1 ypserv-1.3.12-2 If you instead query for the capability /bin/bash, that is, the file /bin/bash, you will see a different list of packages. For example: $ rpm -q --whatrequires /bin/bash apmd-3.0final-34 at-3.1.8-20 autofs-3.1.7-21 autofs-3.1.7-21 bash-2.05-8 bind-9.1.3-4 cipe-1.4.5-6 crontabs-1.10-1 dialog-0.9a-5 gpm-1.19.3-20 hotplug-2001_04_24-11 initscripts-6.40-1 ipchains-1.3.10-10 iproute-2.2.4-14 kudzu-0.99.23-1 logwatch-2.1.1-3 man-1.5i2-6 mkbootdisk-1.4.2-3 mkinitrd-3.2.6-1 mutt-1.2.5i-17 openssh-server-3.1p1-2 pine-4.44-1.72.0 rpm-build-4.0.3-1.03 rusers-server-0.17-12 sendmail-8.11.6-3 shapecfg-2.2.12-7 sharutils-4.2.1-8 sysklogd-1.4.1-4 tetex-1.0.7-30 ucd-snmp-4.2.1-7 vixie-cron-3.0.1-63 xinetd-2.3.3-1 ypbind-1.8-1 ypserv-1.3.12-2 There is no short form for the --whatrequires option. Other capabilities, especially system-level shared libraries, are used by a large number of packages. For example: # rpm -q --whatrequires libcrypt.so.1 | sort autofs-3.1.7-21 cvs-1.11.1p1-3 cyrus-sasl-1.5.24-23 cyrus-sasl-devel-1.5.24-23 cyrus-sasl-plain-1.5.24-23 fetchmail-5.9.0-1 ircii-4.4Z-7 krbafs-1.0.9-2 nss_ldap-172-2 openldap12-1.2.12-4 openldap-2.0.11-13 openldap-clients-2.0.11-13 pam-0.75-19 pam_krb5-1.46-1 passwd-0.64.1-7 perl-5.6.0-17 pine-4.44-1.72.0 pwdb-0.61.1-3 python-1.5.2-35 rsh-0.17-5 rsh-server-0.17-5 screen-3.9.9-3 sendmail-8.11.6-3 shadow-utils-20000902-4 sh-utils-2.0.11-5 SysVinit-2.78-19 tcsh-6.10-6 util-linux-2.11f-17 vim-enhanced-5.8-7 wu-ftpd-2.6.1-20 xinetd-2.3.3-1 ypserv-1.3.12-2 yp-tools-2.5-1 Quite a few packages require encryption and decryption (the purpose of this library), making this library crucial to operating the system. Many of the packages listed here are in turn depended on by even more packages. To help trace back capabilities, you can combine the queries. For example: $ rpm -q --provides sendmail smtpdaemon sendmail = 8.11.6-3 $ rpm -q --whatrequires smtpdaemon fetchmail-5.9.0-1 mutt-1.2.5i-17 The first command lists the capabilities that the sendmail package provides, including the generic capability of smtpdaemon. You can then list which packages require this particular capability, as shown in the second command. This is a big help for wading through a mess of packages depending on packages depending on yet more packages. Determining which package provides a certain capability To complete the circle, you can query for which package provides a certain capability. This knowledge allows you to trace a requirement back to the package that provides it. The --whatprovides option tells the rpm command to list the capabilities a package provides. Use the --whatprovides option with the ???q, or query, option to the rpm command. (There is no short form for the --whatrprovides option.) The basic syntax follows: rpm ???q --whatprovides capability For example, to query what package provides the capability webserver, use the following command: $ rpm -q --whatprovides webserver httpd-2.0.40-8 In this case, the capability is identified by an arbitrary string, webserver. This is a generic name for a given capability, serving Web pages. You can also trace individual files using the --whatprovides option. For example: $ rpm -q --whatprovides /etc/skel/.bashrc bash-2.05-8 Note The rpm ???qf command, covered in the last chapter, is an easier way to get to the same information when tracking which package provides a particular file. For example: rpm -qf /etc/skel/.bashrc bash-2.05-8 If you are querying particular files, use rpm ???qf. If you are querying capabilities, use --whatprovides. Triggers A trigger is a script that gets run when a package is installed or uninstalled. Triggers allow packages that depend on other packages to properly configure themselves when those other packages are installed or removed. The --triggers option to the rpm command lists any trigger scripts in a given package. For example: $ rpm -q --triggers sendmail triggerpostun script (through /bin/sh) -- sendmail < 8.10.0 /sbin/chkconfig --add sendmail This shows that the sendmail mail transfer agent (mail-sending program) provides a short trigger script. In contrast, the anonftp (anonymous file transfer) package has a fairly complex set of triggers, as shown following: $ rpm -q --triggers anonftp triggerin script (through /bin/sh) -- glibc copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null | | cp -df "$file" "$2"; } # Kill off old versions rm -f /var/ftp/lib/ld-* /var/ftp/lib/libc* /var/ftp/lib/libnsl* /var/ftp/lib/lib nss_files* &>/dev/null || : # Copy parts of glibc, needed by various programs in bin. LIBCVER=`basename $(ls --sort=time /lib/libc-*.so |head -n 1) .so |cut -f2- -d-` copy /lib/ld-${LIBCVER}.so /var/ftp/lib copy /lib/libc-${LIBCVER}.so /var/ftp/lib copy /lib/libnsl-${LIBCVER}.so /var/ftp/lib copy /lib/libnss_files-${LIBCVER}.so /var/ftp/lib md5sum /var/ftp/lib/lib*-*.so /var/ftp/lib/libtermcap.so.*.*.* 2>/dev/null >/var /ftp/lib/libs.md5 chmod 0400 /var/ftp/lib/libs.md5 # Use ldconfig to build symlinks and whatnot. [ ! -e /var/ftp/etc/ld.so.conf ] && touch /var/ftp/etc/ld.so.conf /sbin/ldconfig -r /var/ftp triggerin script (through /bin/sh) -- fileutils copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null | | cp -df "$file" "$2"; } copy /bin/ls /var/ftp/bin md5sum `ls /var/ftp/bin/* |grep -v bin.md5` >/var/ftp/bin/bin.md5 chmod 0400 /var/ftp/bin/bin.md5 triggerin script (through /bin/sh) -- cpio copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null | | cp -df "$file" "$2"; } copy /bin/cpio /var/ftp/bin md5sum `ls /var/ftp/bin/* |grep -v bin.md5` >/var/ftp/bin/bin.md5 chmod 0400 /var/ftp/bin/bin.md5 triggerin script (through /bin/sh) -- tar copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null | | cp -df "$file" "$2"; } copy /bin/tar /var/ftp/bin md5sum `ls /var/ftp/bin/* |grep -v bin.md5` >/var/ftp/bin/bin.md5 chmod 0400 /var/ftp/bin/bin.md5 triggerin script (through /bin/sh) -- gzip copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null | | cp -df "$file" "$2"; } copy /bin/gzip /var/ftp/bin ln -sf gzip /var/ftp/bin/zcat md5sum `ls /var/ftp/bin/* |grep -v bin.md5` >/var/ftp/bin/bin.md5 chmod 0400 /var/ftp/bin/bin.md5 triggerin script (through /bin/sh) -- libtermcap copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null | | cp -df "$file" "$2"; } rm -f /var/ftp/lib/libtermcap.so.*.*.* &>/dev/null || : copy '/lib/libtermcap.so.*.*.*' /var/ftp/lib md5sum /var/ftp/lib/lib*-*.so /var/ftp/lib/libtermcap.so.*.*.* 2>/dev/null >/var /ftp/lib/libs.md5 chmod 0400 /var/ftp/lib/libs.md5 # Use ldconfig to build symlinks and whatnot. [ ! -e /var/ftp/etc/ld.so.conf ] && touch /var/ftp/etc/ld.so.conf /sbin/ldconfig -r /var/ftp triggerin script (through /bin/sh) -- ncompress copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null | | cp -df "$file" "$2"; } copy /usr/bin/compress /var/ftp/bin md5sum `ls /var/ftp/bin/* |grep -v bin.md5` >/var/ftp/bin/bin.md5 chmod 0400 /var/ftp/bin/bin.md5 triggerpostun script (through /bin/sh) -- anonftp 4.0 if [ "$2" != 1 ] ; then # The user has multiple glibc packages installed. We can't read the # user's mind, so don't do anything. exit 0 fi copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null | | cp -df "$file" "$2"; } # Kill off old versions rm -f /var/ftp/lib/ld-* /var/ftp/lib/libc* /var/ftp/lib/libnsl* /var/ftp/lib/lib nss_files* &>/dev/null || : # Copy parts of glibc, needed by various programs in bin. LIBCVER=`basename /lib/libc-*.so .so | cut -f2- -d-` copy /lib/ld-${LIBCVER}.so /var/ftp/lib copy /lib/libc-${LIBCVER}.so /var/ftp/lib copy /lib/libnsl-${LIBCVER}.so /var/ftp/lib copy /lib/libnss_files-${LIBCVER}.so /var/ftp/lib copy /bin/ls /var/ftp/bin copy /bin/cpio /var/ftp/bin copy /bin/tar /var/ftp/bin copy /bin/gzip /var/ftp/bin ln -sf gzip /var/ftp/bin/zcat copy /usr/bin/compress /var/ftp/bin rm -f /var/ftp/lib/libtermcap.so.*.*.* &>/dev/null || : copy '/lib/libtermcap.so.*.*.*' /var/ftp/lib # Use ldconfig to build symlinks and whatnot. [ ! -e /var/ftp/etc/ld.so.conf ] && touch /var/ftp/etc/ld.so.conf /sbin/ldconfig -r /var/ftp # Generate md5sums for verifyscript md5sum /var/ftp/lib/lib*-*.so /var/ftp/lib/libtermcap.so.*.*.* 2>/dev/null >/var /ftp/lib/libs.md5 chmod 0400 /var/ftp/lib/libs.md5 md5sum `ls /var/ftp/bin/* |grep -v bin.md5` >/var/ftp/bin/bin.md5 chmod 0400 /var/ftp/bin/bin.md5 Reading through the scripts indicates that this package seems to be triggered by the glibc standard C programming library package. You can confirm this by using the --triggeredby option to the rpm command, as shown following: $ rpm -q --triggeredby glibc anonftp-4.0-9 The anonftp package needs to be notified on changes to the glibc package, so that the anonftp package can properly set up its application. It actually uses part of glibc and is therefore highly susceptible to changes in the glibc package. Thus, the use of triggers provides essentially an extended form of dependencies. The anonftp package in this example depends so much on the glibc package that it needs to execute scripts whenever the glibc package changes. Summary Linux comes with many packages. Most of these packages depend on some other packages installed on your system. In RPM terms, packages provide capabilities and depend on capabilities that other packages provide. When the rpm command checks the RPM database for dependencies, it checks to ensure that all the capabilities that a given package requires are met by other installed packages. You can trace the capabilities a package requires with the --requires option to the rpm command. You can see what capabilities a package provides for others with the --provides option. Once you know a capability, you can query which package provides that capability with the --whatprovides option to the rpm command. And you can see which packages require that capability with the --whatrequires option. Triggers are an extended form of dependencies. A trigger is a script that gets executed when other packages are installed or removed. This allows a package with a high dependence on another package to track changes in that package and reconfigure itself as needed. The next chapter delves into transactions, which provide a safe means to install a set of packages. With transactions, either all the packages get installed, or none. From fedora-docs-commits at redhat.com Tue Oct 4 01:50:11 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:50:11 -0400 Subject: rpm-guide rpm-guide-development-tools-en.xml,NONE,1.1 Message-ID: <200510040150.j941oB7t000510@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv492 Added Files: rpm-guide-development-tools-en.xml Log Message: --- NEW FILE rpm-guide-development-tools-en.xml --- Linux Text Editors and Development Tools Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Appendix *General text editors *C-specific tools and integrated development environments *Python-specific development tools Linux includes a number of text editors and integrated development environments (IDEs), going from plain old text editors all the way up to sophisticated tools. These tools are suitable for shell scripting, C, Python, and Perl programming, along with a plethora of other uses. Linux makes extensive use of text files, especially for configuration data, so Linux has always included a number of text editors. This appendix lists a number of tools for those who have not yet set up an RPM development environment on Linux. Note that choosing an editor or IDE is mostly a matter of personal taste. Programmers will often engage in raging battles over the superiority of text editors and other programming tools. Before searching around too far, try out what you have installed on your system and see if that works for you. Note that Internet sites may change or disappear, so you may have to search to find these tools. General Text Editors Linux distributions include a number of text editors with varying sets of features. The two most common editors are vi and emacs, which come with virtually all Linux distributions. These editors are good for UNIX- or Linux-savvy developers, but generally have a steep learning curve for developers used only to Windows. If you come from Windows, try gedit, kedit, or kate. These text editors open a graphical window on your desktop, making them appear more or less like the Windows Notepad.exe. All three offer more features than Notepad.exe, however. You may not have installed any of these editors, but all are available as part of Red Hat Linux. You can install vi, emacs, gedit, kedit, or kate from the packages that come with your Linux distribution. To start one of the editors, enter a command like the following: $ gedit listrpmpkgs & The ampersand, &, launches the program in the background. Replace gedit with the editor you choose. Programming Text Editors In addition to general-purpose text editors, Linux sports a large number of text editors with special features for programming, such as syntax highlighting. The extended version of vi, called vim, includes a number of add-ons that can help you with C programming tasks. Emacs also includes a wide array of features to help programming. Both of these editors can act as development environments with a bit of configuration. As mentioned previously, both come with most Linux distributions. I also like an editor called nedit and another one called jedit. The jedit editor is written in Java, so that it runs the same on Windows and Linux, a big win if you must work on multiple platforms. (Emacs and vim have versions that work on Windows, too, along with Linux.) If you use jedit, you must have a Java runtime environment installed. Cross Reference Download nedit from www.nedit.org. Download jedit from www.jedit.org. Download Java runtime environments from Sun at http://java.sun.com/j2se/downloads.html or IBM at www.ibm.com/java/jdk/ and select the IBM Developer Kit for Linux. Integrated Development Environments for C Programming If you want more of a graphical environment, Red Hat Linux ships with KDevelop, an IDE for C and C++ programming. Anjuta provides a GTK/GNOME-based IDE, an alternative to the KDE-based KDevelop. KDevelop, however, supports KDE, GNOME, Qt, and text-mode C and C++ applications. Cross Reference Download Anjuta from www.anjuta.org. The Eclipse IDE, while mostly used for Java development, has a C and C++ mode called CDT, for C/C++ Development Tools. Eclipse is important because Red Hat provides an RPM-building plug-in to Eclipse. Cross Reference Download Anjuta from www.anjuta.org. Download Eclipse from www.eclipse.org and the Eclipse CDT from www.eclipse.org/tools/downloads.html. Integrated Development Environments for Python Programming As with C programs, Python scripts are made up of text files holding Python commands, so you need a text editor or some sort of development environment for creating Python programs. Any of the tools listed so far will work fine for developing Python applications. The key requirement is the ability to control tabs and indenting, since this is crucial to Python syntax. IDLE, a graphical console and editor, supports creating Python applications. This is considered part of Python. IDLE requires the Python-tools package. In addition, you can choose from Python-focused tools such as Bicycle Repair Man, a refactoring tool, or Boa Constructor and Black Adder, two Python IDEs. Cross Reference Boa Constructor is available from http://boa-constructor.sourceforge.net. Black Adder is a commercial tool available at www.thekompany.com. The Eclipse IDE, mentioned previously, supports a number of Python add-ons. Combined with the C and C++ tools, and plug-ins for building RPMs, Eclipse brings together most everything you need for Python development on Linux. Cross Reference Eclipse is available at www.eclipse.org, and Python add-ons at http://sourceforge.net/projects/pyeclipse, http://sourceforge.net/projects/pe4eclipse, or http://www.kalab.com/freeware/pythoneclipse/pythoneclipse.htm. This is really just the tip of the iceberg when it comes to Python tools. You can find many more available on the Internet. Cross Reference A large listing of Python editing tools appears at http://www.python.org/cgi-bin/moinmoin/PythonEditors. From fedora-docs-commits at redhat.com Tue Oct 4 01:50:52 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:50:52 -0400 Subject: rpm-guide rpm-guide-en.xml,NONE,1.1 Message-ID: <200510040150.j941oqki000544@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv521 Added Files: rpm-guide-en.xml Log Message: --- NEW FILE rpm-guide-en.xml --- %FEDORA-ENTITIES-EN; ]> RPM Guide 2005 Eric Foster-Johnson Foster-Johnson Eric &LEGALNOTICE; 0.1 2005-10-03 StuartEllis First commission to CVS &PACKAGINGINTRO; &RPMINTRO; &RPMOVERVIEW; &USINGRPM; &USINGRPMDB; &DEPENDENCIES; &TRANSACTIONS; &MANAGEMENT; &CREATING; &SPECFILES; &ADVPACKAGING; &RPMBUILD; &PACKAGINGTOOLS; &GUIDELINES; &SCRIPTING; &PROGRAMMINGC; &PROGRAMMINGPY; &PROGRAMMINGPL; &OTHERLINUXES; &OTHEROS; &CUSTOMIZINGRPM; &COMMANDREF; &SPECFILESYN; &RPMEVOLUTION; &RPMSTRUCTURE; &RESOURCES; &DEVTOOLS; &LICENSING; From fedora-docs-commits at redhat.com Tue Oct 4 01:51:55 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:51:55 -0400 Subject: rpm-guide rpm-guide-extra-packaging-tools-en.xml,NONE,1.1 Message-ID: <200510040151.j941ptdK000577@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv559 Added Files: rpm-guide-extra-packaging-tools-en.xml Log Message: --- NEW FILE rpm-guide-extra-packaging-tools-en.xml --- Supplemental Packaging Software Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Chapter *Understanding packaging aids *Manipulating packages RPM is intended to make system management easier, both for system administrators and other users who do all the day-to-day work of installing and removing applications and for developers and other users who do all the work of preparing applications for installation. For RPM packagers, the work involved in preparing an application for installation has two phases: first, the software must be compiled (if it is not written in an interpreted language such as Perl) and otherwise configured for the system on which it will be installed; then the RPM package of the software must be prepared by creating a spec file that properly packages it into an RPM. In contrast, packagers who choose to package applications in a simpler format, such as gzipped tarballs (compressed tar archives), have less work ahead of them, since they need only concern themselves with the first step. After a packager has prepared an RPM package once, RPM makes the first step (compilation and configuration) easier when the packager has to package an updated version of the same software; RPM does a lot of work to track compilation commands, any needed patches, and any configuration modifications discovered to be necessary to prepare the software. Similarly, once an RPM spec file has been produced for an application, updating that spec file to support a newer version of that application is usually trivial. For these reasons, using RPM instead of a simpler, less end-user-friendly package format (such as gzipped tarballs) is a bit of a tradeoff for the packager; preparing an RPM of an application requires a little more initial time and work than preparing a gzipped tarball of that same application, but once created, the RPM package takes less time and effort to keep current than the gzipped tarball requires. Packaging Aids However, several helper tools are also available for RPM packagers. These tools can be used at various stages in the process of producing a high-quality RPM package to simplify the tasks that an RPM packager must perform. These tools include syntax-highlighting modes for various text editors, making production and maintenance of spec files easier; macro packages for popular text editors, simplifying the generation and maintenance of spec files; tools that generate spec files, simplifying initial spec file creation; and debuggers that validate produced binary RPMs, helping ensure that the spec file used to create the packages is accurate and high quality. Using VIM spec plugins to improve spec file editing Unix systems have traditionally shipped the legendary (or notorious, depending upon your point of view) vi editor (pronounced vee eye) as their default text editor. Vi was initially developed by Bill Joy in 1976 for BSD Unix. It eventually was incorporated in AT& T System V Unix as well and later was mandated by the POSIX 1003 standards (which define what an OS must have to be Unix-compatible), thereby conquering all facets of the Unix world. The original vi source code is no longer freely available, but several clones of the vi program have been created over the years. The most popular of these vi clones is probably Vi IMproved, or VIM (www.vim.org). VIM is the standard vi implementation (meaning that when you type vi at the command prompt, the program you really are running is vim) on many Linux distributions, including Red Hat Linux. It is also freely available for most other Unixes and even for non-Unix systems such as Microsoft Windows. VIM is a fully backwards-compatible implementation of the original vi editor, although it also offers many additional features that vi did not support. One VIM feature that can be extremely useful when preparing spec files is colorized syntax highlighting. VIM has an extensible interface through which it can be told about the syntax used for files of various types. Once it understands a filetype's syntax, it can color the various syntactic structures of that file in different ways. For example, when editing a Bourne shell script using VIM, comments are typically blue, control statements (if, for, do, and so on) are yellow, variables are purple, and so forth. Many people find this feature very useful, since a single glance reveals the entire logical structure of the file. Furthermore, errors in the file (such as a missing done statement failing to close a do loop in a Bourne shell script) are often immediately obvious when using such a colorizing editor. Usually, VIM does not understand the structure of RPM spec files. When preparing a spec file, VIM displays all text in the same color. A spec.vim syntax file is available for VIM that makes VIM aware of the syntax used for RPM spec files. When this file is used, the various structural components (%define, preamble statements, %build, and so forth) are all colorized, making the logic of the spec file readily apparent. The spec.vim file that provides VIM with an understanding of spec-file syntax is bundled with newer versions of VIM, or it can be downloaded from the Internet. Most RPM-based Linux distributions, including Red Hat Linux, ship this file with VIM as part of their distribution and even automatically configure VIM to load this syntax file any time an RPM spec file is being edited. When using VIM on a system that does not automatically load spec.vim whenever spec files are edited, you should download the spec.vim file (I tend to save such personal extensions in ~/etc/vim, but you can save it any place you prefer). Cross Reference Download the spec.vim syntax file for VIM from http://pegasus.rutgers.edu/~elflord/vim/syntax/spec.vim. Once downloaded, configure VIM to load your new syntax file. You can do this by putting the following in your ~/.vimrc file (assuming you have saved the file as ~/etc/vim/spec.vim; adjust the path as necessary if you saved it elsewhere): augroup syntax au! BufNewFile,BufReadPost *.spec so ~/etc/vim/spec.vim au BufNewFile,BufReadPost *.spec so ~/etc/vim/spec.vim augroup END This statement will instruct VIM to load the syntax file whenever a file named with a .spec extension is edited. You can now even customize the colors which VIM uses, if you like, by editing ~/etc/vim/spec.vim! The VIM editor has hundreds of built-in commands for formatting text. If necessary, it can even be extended with new commands. Furthermore, these commands can be defined in FileType plugins, so that different commands are loaded depending upon the type of file being edited (just as different syntax matching can be used depending upon the type of file being edited). Gustavo Niemeyer has written a spec plugin, pi_spec, which defines various commands that can be used when working with RPM spec files. Currently, this plugin can be used to automate maintenance of the %changelog section of RPM spec files. By default, the spec plugin provides a macro, spec_chglog, which is mapped to the <LocalLeader>-c key. Normally, the LocalLeader key in VIM is mapped to "\", a backslash character. This means you press \c to load the spec_chglog macro. If desired, you can instead map spec_chglog to a different key by putting a statement like the following in your ~/.vimrc file. au FileType spec map <buffer> C <Plug>SpecChangelog In this case, that statement would map the macro to the "C" key, but you can map it to a different key by replacing the "C" in the statement with whichever key or key combination you prefer. The spec_chglog macro checks the %changelog in the spec file currently being edited and makes sure that the last entry in this %changelog was written today and was written by you. If it was, the macro adds a new item to the entry. If it was not written today, or was written today, but not by you, the macro adds an entirely new entry. Optionally, the macro also checks that the name, version, and release of the package are correct and will update the release if it is incorrect. In addition, the macro maps the percent key, %, making it usable in command mode in VIM to move quickly between sections within a spec file. To help spec_chglog, you can define a few variables in your ~/.vimrc file to customize its behavior. The variable spec_chglog_format defines what the macro uses for new %changelog entries. If you do not define this variable, the macro will ask you for an e-mail address and construct it for you the first time you use the macro. Alternatively, you can customize it yourself by adding an entry like the following to your ~/.vimrc file. let spec_chglog_format = "%a %b %d %Y Your Name <your at email.address>" The preceding format is what Red Hat's developers use for Red Hat Linux spec files and results in a %changelog entry that looks like the following, with the user name and e-mail address changed to protect the innocent: * Mon Apr 15 2002 Bob Marley <bob at marley.yow> The variables in the spec_chglog_format control the time format that is used. If you want different time formats in your %changelog entry, you can replace the variables (using %A instead of %a would cause the full weekday name, such as "Monday", to be printed) using the documentation in the strftime(3) man page as a guideline. By default, the macro will insert new entry items after existing items. For example, if I already have a %changelog entry for today that reads as follows: * Mon May 6 2002 Bob Marley <bob at marley.yow> - Updated to newest release Then, using the macro to add a new entry for an additional patch I added will, by default, result in an entry that reads: * Mon May 6 2002 Bob Marley <bob at marley.yow> - Updated to newest release - Added Solaris compile patch If I want, I can instead have new items inserted before existing items, so that my second entry instead looks like * Mon May 6 2002 Bob Marley <bob at marley.yow> - Added Solaris compile patch - Updated to newest release To have new items inserted before existing items, simply add the following line to your ~/.vimrc file: let spec_chglog_prepend = 1 Optionally, the macro can track version and release numbers in the %changelog entries automatically. Adding the line let spec_chglog_release_info = 1 results in the first item in every changelog entry automatically reflecting the version and release, so that my %changelog entry might instead look like the following: * Mon May 6 2002 Bob Marley <bob at marley.yow> + httpd-2.0.36-2 - Updated to newest release - Added Solaris compile patch If this feature is enabled, the macro automatically checks the version and release information to make sure that they have increased. If they haven't, it will offer to update them for you. Add the following line to your ~/.vimrc file to disable this feature, if necessary. let spec_chglog_never_increase_release = 1 This spec plugin ships with newer versions of VIM. Both it and the VIM spec syntax highlighting extensions can be very useful for speeding spec file editing and debugging, and are well worth trying out if you are a VIM user. Cross Reference You can find out more about vim at www.vim.org. Adding functions with emacs rpm-spec-mode Of course, not everyone in the world uses VIM. Another commonly used editor is the emacs editor originally developed by Richard M. Stallman. Unlike vi, emacs is not considered an essential Unix component and is not always found installed on a Unix system, although it is bundled with just about every Linux distribution. Over the years, two major emacs variants have emerged. GNU Emacs is produced by the Free Software Foundation and can be downloaded from www.gnu.org/software/emacs/emacs.html. XEmacs is based on GNU Emacs and is available from www.xemacs.org. Historically, the two differed in their user interfaces (XEmacs, as the name suggests, had an X Window interface, though GNU Emacs has one as well these days) and in some technical details of how they operated. Both are freely available under the terms of the GNU GPL, so you can download and try either or both if they are not already on your system. Cross Reference See Appendix G for more on the GNU GPL, or General Public License. Red Hat Linux includes RPMs of both GNU Emacs and XEmacs as part of the distribution, and most other Linux distributions will include one or both as well. Like VIM, both GNU Emacs and XEmacs support syntax highlighting. They are also both extensible, having the ability to load mode files that add new commands and functions. Stig Bj??rlykke has written a mode, rpm-spec-mode.el, which works with both GNU Emacs and with XEmacs to add many functions, making it easier to use when editing RPM spec files. Red Hat Linux includes and enables this mode in both GNU Emacs and XEmacs, as do many other Linux distributions. Cross Reference You can download this emacs mode from http://tihlde.org/~stigb/rpm-spec-mode.el. After downloading, you will need to put the following lines in your ~/.emacs init files (for GNU Emacs) or ~/.xemacs init files (for XEmacs) to instruct emacs to load rpm-spec-mode whenever a file with a .spec extension is being edited: (autoload 'rpm-spec-mode "rpm-spec-mode.el" "RPM spec mode." t) (setq auto-mode-alist (append '(("\\.spec" . rpm-spec-mode)) auto-mode-alist)) Once installed, rpm-spec-mode will provide emacs with additional support for editing RPM spec files. Figure 13-1 shows this mode in GNU Emacs. 54965-0 Fg1301.tiff here; needs to be cropped to just the central window Figure 13-1: Gnu Emacs using rpm-spec-mode Figure 13-2 shows this mode in XEmacs. 54965-0 Fg1302.tiff here; needs to be cropped to just the central window Figure 13-2: XEmacs using rpm-spec-mode With this mode, emacs can do syntax highlighting of spec files, just like VIM. The mode file rpm-spec-mode.el contains the emacs instructions that specify what should be highlighted and what colors should be used for highlighting. Tip If you do not see syntax highlighting when you edit a spec file, your emacs session may or may not be currently configured to do syntax highlighting. First, make sure that the status bar at the bottom of your emacs window says (RPM-SPEC), indicating that rpm-spec-mode is being used. If it doesn't, double-check the rpm-spec-mode installation instructions. If the status bar does indicate that you are using rpm-spec-mode, also double-check that syntax highlighting (which, in emacs, is a global configuration option) has been enabled. In both GNU Emacs and XEmacs, the Options menu has a Syntax Highlighting option that must be enabled before emacs will colorize spec file syntactic structures. In addition to providing syntax colorization, rpm-spec-mode adds a variety of new functions to emacs that can be used to speed the process of creating or editing RPM spec files. These new functions appear on the RPM-Spec menu that is added to emacs by rpm-spec-mode. Many of the functions are similar to the functions added to VIM by the spec_chglog macro. Navigation functions to move quickly through a spec file are provided, so that Ctrl+C, Ctrl+N (press Ctrl+C followed by Ctrl+N) will move the cursor to the next major section of the spec file, while Ctrl+C, Ctrl+P will move the cursor to the prior major section of the spec file. Similarly, macros are also defined to increment the release tag (Ctrl+C, R) and the very handy option to add new %changelog entries (Ctrl+C, E). Like the VIM macros for adding %changelog entries, the rpm-spec-mode command checks to see if an entry already exists for today. If not, it adds a new entry, but if so, it just adds a new item to the existing entry. For %changelog entries to have the correct e-mail address, the emacs variable user-mail-address must be set correctly. If it is not set on your system, you can add the following line to your emacs initialization files: (setq user-mail-address "your at email.address") In addition to these basic functions, rpm-spec-mode offers more advanced spec file creation support. Opening a new buffer in emacs for a spec file that does not already exist automatically generates a skeleton spec file. To further speed things up, emacs offers a number of macros for the main tasks in writing an RPM spec file. Table 13-1 lists these macros. Table 13-1Macro commands for The RPM SPEC MODE IN EMacs Command Function Ctrl+C Tab Adds a new tag to the spec file Ctrl+C Ctrl+F F Adds a new file to the %files section Ctrl+C Ctrl+F C Adds a new configuration file to the %files section Ctrl+C Ctrl+F D Adds a new documentation file to the %files section Ctrl+C Ctrl+F G Adds a new ghost file to the %files section Ctrl+C Ctrl+D D Adds a new directory to the %files section Ctrl+C Ctrl+D O Adds a new documentation directory to the %files section Ctrl+C Ctrl+C U Changes the umask in %defattr entries in %files Ctrl+C Ctrl+C O Changes the owner in %defattr entries in %files Ctrl+C Ctrl+C G Changes the group in %defattr entries in %files Furthermore, rpm-spec-mode even adds macros to emacs that can be used to build RPMs from spec files without even having to exit emacs! Since the process of constructing spec files is often iterative (make new spec, build RPM from spec, find mistake, edit spec, build RPM from spec, find mistake, and so on), this capability of emacs to be used as an IDE for RPM package generation is extremely useful. Basic macros exist to do complete builds (Ctrl+C B to build a binary package, Ctrl+C S to build a source package, and Ctrl+C A to build both). Macros can also be used to execute various intermediate steps, such as the %prep stage (Ctrl+C P), the %build stage (Ctrl+C C), or the %install stage (Ctrl+C I). Various options of the build process can also be controlled, such as GPG-signing of generated packages. If you are a user of GNU Emacs or XEmacs, you should definitely take the time to learn to use rpm-spec-mode. Being able to build packages from within the editor where you are editing the spec file that builds those packages is a great productivity gain for many people. Validating and debugging spec files with rpmlint Both VIM and emacs extensions help with the process of initially creating spec files and with the maintenance of existing RPM spec files. After a spec file has been created, and RPMs have been created using that spec, the binary RPMs generated from the spec can be validated using the rpmlint command. The name rpmlint comes from lint, the traditional Unix utility that can "sanity-check" C source code, looking for certain classes of common C coding mistakes. The idea behind rpmlint is similar; it processes binary RPMs, checking for certain common mistakes made by RPM packagers. The rpmlint command currently ships with a wide variety of checks and is written using a modular interface so that additional checks can easily be added if needed. Currently, rpmlint can check that all binary files in the package are correct (making sure that a .noarch.rpm package does not contain binary files, that no binaries are being installed in /etc, that the binary file types in the package are appropriate for the package architecture, that shared libraries are configured correctly, and that all executables are stripped). It can also check the validity of files marked as configuration files in the RPM (ensuring that configuration files are only being installed in /etc, not in /usr) and that the package file complies with the distribution's policies for packages (checking things such as the compression of man pages and Info pages and the correctness of vendor and distribution fields in the package header). In addition, rpmlint performs a variety of checks to ensure that the package complies with the Filesystem Hierarchy Standard (verifying that files are installed in their standard locations on the system), the Linux Standards Base (verifying that package-file naming is LSB-compliant) and that files have correct ownerships and permissions. Init scripts are double-checked (for packages that have init scripts) to ensure that the basic structure of the init script is correct and that appropriate %post and %preun configuration directives are being run to configure the init script on the system. %post, %pre, and %preun scripts are also double-checked (ensuring that only valid interpreters are specified for scripts and that scripts are written in valid syntax). The validity of the package itself is also checked in various ways (ensuring that the package is GPG-signed, that the package's source RPM is correctly prepared, that the package spec file uses correct syntax, and that all tags used in the package header are valid). Cross Reference To find out more about the Filesystem Hierarchy Standard, see www.pathname.com/fhs/. To find out more about the Linux Standards Base, see www.linuxbase.org. Download rpmlint from www.lepied.com/rpmlint. It is written entirely in Python, so a Python interpreter is necessary to run it. Once installed, rpmlint can be configured on a system-wide basis, using the /etc/rpmlint/config file, or on a per-user basis, using the $HOME/.rpmlintrc file. This file can specify checks to perform, check output that should be ignored, and configuration options. Configuration options can be specified, listing what entries are valid for various fields in the RPM header, such as the Vendor and Packager fields. By default, Red Hat Linux ships with this configuration file set to validate packages to make sure they are suitable for Red Hat Linux; if packaging for a different distribution, this file might need to be modified. Once rpmlint has been installed and configured, it can be run against RPMs. For example, rpmlint helps with creating packages, such as tin (a popular Usenet client) for Red Hat Linux, since it is not included with the distribution. After preparing a tin spec file, then building RPMs from that file, you can typically double-check them using rpmlint. For example, when running rpmlint on a source RPM, you???ll see output like the following: $ rpmlint tin-1.5.12-1.src.rpm E: tin no-packager-tag W: tin invalid-license distributable W: tin no-url-tag W: tin strange-permission tin-1.5.12.tar.bz2 0664 W: tin obsolete-tag Copyright $ For the most part, this package looks fine according to the rpmlint output. The permissions on the tin source code can be changed (0644 is the "preferred" permissions), and you might want to change my spec file to use the License tag instead of the now-obsolete Copyright tag. Similarly, you might want to add a URL tag to the package to point to the URL for the software. When running rpmlint on a binary RPM, you???ll see output like the following: $ rpmlint tin-1.5.12-1.i386.rpm W: tin invalid-vendor None W: tin invalid-distribution None E: tin no-packager-tag W: tin invalid-license distributable W: tin no-url-tag $ With this output, the binary package looks fine. You should set a I don???t bother setting a vendor, distribution, and packager but you can ignore those warnings. Similarly, rpmlint warns because it does not recognize the license type used, "distributable". You can fix this, you can ignore this, or you can modify /etc/rpmlint/config so that rpmlint recognizes "distributable" as a valid license. The sorts of validity checks that rpmlint can do make it valuable for ensuring the quality and consistency of RPMs. Most RPM-based Linux distributions validate their entire distribution using rpmlint. Using it for packages you prepare is a good idea as well. Generating the %files section with RUST For the most part, maintaining RPM spec files is relatively straightforward. Creating spec files from scratch, however, can be a little bit more challenging. Tools like rpm-spec-mode for emacs can help with the process, generating skeleton spec file templates that can be filled in, but these sorts of tools do not address the step that most new RPM packagers seem to find most difficult: generating the %files section. Creating a complete, accurate list of all needed files supplied by an application can be difficult, particularly when it is an application with which you are unfamiliar. Most software supports installation to a temporary location; if the software you are packaging allows this, generation of %files is (almost) as simple as using BuildRoot to install the application to a temporary directory, then running an ls -lR command in that subdirectory to see all the installed files and directories. Even then, though, the output from ls -lR must be cleaned up and converted into %files format for adding to the spec file. All of this takes time. A couple of tools exist to reduce the amount of work needed for this stage of the process, automating the generation of the %files section of spec files. The most sophisticated of these toolsets is RUST. Cross Reference Download RUST from www.rusthq.com. RUST consists of two tools: crust and rust. The crust command provides a command-line tool that can create a chroot() jail, in which software can be built and installed, and then automatically generate a spec file that documents the files that were installed. This not only eliminates the need to generate a %files section for a spec file manually but also removes the need to modify software to support installation to a temporary location using BuildRoot, a sometimes difficult task. The rust command provides a graphical front end to the crust command, as shown in Figure 13-3. 54965-0 Fg1303.tiff here Figure 13-3: rust, a drag-and-drop spec file generator The rust command provides a graphical interface that can be used to control crust and supports drag-and-drop creation of spec files. In the rust interface, two file trees are displayed. The left-hand tree displays the local file system, while the right-hand tree displays the file tree inside the crust chroot() jail. Files that should be packaged together can just be dragged from their current locations on the system (displayed in the left-hand tree) to their final destinations in the right-hand tree. You can then click the makeRPM choice to generate an RPM containing those files. Although not terribly useful for packages being generated from source code, this feature can greatly simplify creation of RPMs of applications that are only supplied in binary format (such as the Linux Adobe Acrobat reader). RUST's rust application can be useful in some circumstances (providing new developers a graphical tool that can be used to generate binary RPMs), and crust is more generally useful for packaging difficult-to-package software that needs to be built and installed in a chroot() jail. Unfortunately, development of RUST appears to have stopped, so extension of RUST to become a more generally useful IDE for RPM generation is not likely to happen. However, the project is licensed under the GNU GPL (Appendix G), so it might be resumed by another developer or team of developers. setup.sh and MakeRPM.pl Other tools that have been developed to simplify the process of creating an RPM spec file take an entirely different approach. Tools such as setup.sh, available from www.mmedia.is/~bre/programs/setup.sh, are intended to function as wrappers around the existing build commands (./configure and make) for software. These types of tools take the approach of using the standard build tools for software (since those tools must always be used to build the software, whether using RPM or compiling the software from a source tarball) and capturing the output to generate an RPM spec file automatically. The MakeRPM.pl Perl script, available from www.perl.com/CPAN/modules/by-authors/id/JWIED, is another example of such an approach. MakeRPM.pl is a more specialized tool than setup.sh, as MakeRPM.pl is intended only for producing RPMs from Perl modules packaged in CPAN (www.cpan.org). It is implemented as a wrapper around the standard commands (perl Makefile.PL ; make ; make test ; make install) used to install Perl CPAN software. MakeRPM.pl actually works quite well for its intended purpose at mdproducing packages of CPAN modules. The setup.sh script is currently viewable mainly as a proof of concept, rather than being a generally universal automatic spec file generator. In the future, when spec files are likely to be representable using a formal closed-syntax grammar, it is possible that more generalized spec file generation tools will be developed. Until that time, however, some of the previously mentioned tools, particularly the VIM and emacs extensions, can provide assistance when manually generating spec files. Cross-reference For more discussion of the future of RPM, you can turn to Chapter 22. Manipulating Package Files with rpm2cpio Normally, RPM packagers are concerned with taking source code or binary files, and producing an RPM that contains those files and can be used to install them on end-users' systems. Sometimes, packagers and end users find themselves in the opposite position, that of having a source or binary RPM package file and needing to extract its contents. An RPM can always be installed to access its contents (either source code, patches, and a spec file which get put under %_topdir for a source RPM, or software which gets put in system directories for a binary RPM), but that is often overkill. I frequently want to extract a single patch file, or the spec file, from a source RPM, but I don't really need to install the entire source RPM. Similarly, people often want to extract the contents of RPMs on systems that do not come with RPM, such as Solaris. Fortunately, tools are available that can process RPM package files into a format from which their content can be extracted. Structurally speaking, RPM package files are compressed cpio archives that have additional binary data added to the beginning containing various meta-data about the package (specifying its architecture and OS, for example), a GPG signature if the package is signed, and so forth. If this binary data is removed from the beginning of the RPM package file, the remainder is a System V Release 4-style cpio file that can be manipulated using any reasonably complete cpio command. Several different tools, each sporting the name rpm2cpio, are available which can do this binary data removal, converting an RPM package file into a standard cpio archive. RPM ships with an rpm2cpio utility that can be used to convert RPM package files to cpio files. (Chapter 3 introduces the rpm2cpio utility.) For example, if you have a source RPM package file and want to extract its files without having to install it, you can process it through rpm2cpio. The rpm2cpio command takes as input an RPM package file, and produces a cpio file on standard output. For example, to redirect the output to a file, use a command like the following: $ rpm2cpio fluxbox-0.1.8-2.src.rpm > fluxbox-0.1.8-2.cpio $ This command creates a cpio archive from the package. You can later use cpio commands on the output file. You can also pipe the output of rpm2cpio through the cpio command: $ rpm2cpio fluxbox-0.1.8-2.src.rpm | cpio -i -d 656 blocks $ This command extracts the contents of the package. This rpm2cpio command is bundled with RPM and is installed on most RPM-based Linux distributions, including Red Hat Linux. However, it is less useful on systems that do not come with RPM, such as Solaris. This "standard" implementation of rpm2cpio is written in C, and so must be compiled before it can be used. Since most commercial Unix systems do not come with a C compiler by default (unlike Linux and other free Unixes, such as the BSD operating systems), compiling this rpm2cpio code can be a major undertaking. Fortunately, rpm2cpio implementations are also available in a couple of other languages, in more easy-to-install formats for other operating sytsems, including as a Bourne shell script or a Perl script. The Bourne shell syntax should work on any reasonably modern Unix system (and even a few non-Unix systems; it also works on Microsoft Windows under cygwin, for example). The script in Listing 13-1should be saved to a file named rpm2cpio.sh, marked executable, and copied to a directory in your path. Listing 13-1: rpm2cpio as a Bourne Shell script #!/bin/sh pkg=$1 if [ "$pkg" = "" -o ! -e "$pkg" ]; then echo "no package supplied" 1>&2 exit 1 fi leadsize=96 o=`expr $leadsize + 8` set `od -j $o -N 8 -t u1 $pkg` il=`expr 256 \* \( 256 \* \( 256 \* $2 + $3 \) + $4 \) + $5` dl=`expr 256 \* \( 256 \* \( 256 \* $6 + $7 \) + $8 \) + $9` # echo "sig il: $il dl: $dl" sigsize=`expr 8 + 16 \* $il + $dl` o=`expr $o + $sigsize + \( 8 - \( $sigsize \% 8 \) \) \% 8 + 8` set `od -j $o -N 8 -t u1 $pkg` il=`expr 256 \* \( 256 \* \( 256 \* $2 + $3 \) + $4 \) + $5` dl=`expr 256 \* \( 256 \* \( 256 \* $6 + $7 \) + $8 \) + $9` # echo "hdr il: $il dl: $dl" hdrsize=`expr 8 + 16 \* $il + $dl` o=`expr $o + $hdrsize` dd if=$pkg ibs=$o skip=1 2>/dev/null | gunzip After you have marked this file as executable and placed it in your command path, you can use the script just like the C language implementation of rpm2cpio. This script also takes an RPM package file as input and produces a cpio file on standard output, and so should be used in conjunction with redirection or a pipe: $ rpm2cpio.sh fluxbox-0.1.8-2.src.rpm | cpio -i -d 656 blocks $ In this case, I piped the output to cpio, directly extracting it. I could have redirected the output of rpm2cpio.sh to a file instead. In addition to the Bourne shell implementation of rpm2cpio, a version has been written in Perl by Roger Espel Llima. The Perl rpm2cpio implementation should work on any system that has a reasonably modern Perl interpreter. To use this version of rpm2cpio, the script in Listing 13-2 should be saved to a file named rpm2cpio.pl, marked executable, and copied to a directory in your path. Listing 13-2:The Perl version of rpm2cpio, rpm2cpio.pl #!/usr/bin/perl # Copyright (C) 1997,1998,1999, Roger Espel Llima # # Permission is hereby granted, free of charge, to any person obtaining a copy # of this software and any associated documentation files (the "Software"), to # deal in the Software without restriction, including without limitation the # rights to use, copy, modify, merge, publish, distribute, sublicense, # and/or sell copies of the Software, and to permit persons to whom the # Software is furnished to do so, subject to the following conditions: # # The above copyright notice and this permission notice shall be included in # all copies or substantial portions of the Software. # # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE # SOFTWARE'S COPYRIGHT HOLDER(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER # LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN # THE SOFTWARE # (whew, that's done!) # why does the world need another rpm2cpio? because the existing one # won't build unless you have half a ton of things that aren't really # required for it, since it uses the same library used to extract RPM's. # in particular, it won't build on the HPsUX box i'm on. # sw 2002-Mar-6 Don't slurp the whole file # add a path if desired $gzip = "gzip"; sub printhelp { print <<HERE; rpm2cpio, perl version by orabidoo <odar\@pobox.com> +sw dumps the contents to stdout as a cpio archive use: rpm2cpio [file.rpm] > file.cpio Here's how to use cpio: list of contents: cpio -t -i < /file/name extract files: cpio -d -i < /file/name HERE exit 0; } if ($#ARGV == -1) { printhelp if -t STDIN; $f = "STDIN"; } elsif ($#ARGV == 0) { open(F, "< $ARGV[0]") or die "Can't read file $ARGV[0]\n"; $f = 'F'; } else { printhelp; } printhelp if -t STDOUT; # gobble the file up ##undef $/; ##$|=1; ##$rpm = <$f>; ##close ($f); read $f,$rpm,96; ($magic, $major, $minor, $crap) = unpack("NCC C90", $rpm); die "Not an RPM\n" if $magic != 0xedabeedb; die "Not a version 3 or 4 RPM\n" if $major != 3 && $major != 4; ##$rpm = substr($rpm, 96); while (!eof($f)) { $pos = tell($f); read $f,$rpm,16; $smagic = unpack("n", $rpm); last if $smagic eq 0x1f8b; # Turns out that every header except the start of the gzip one is # padded to an 8 bytes boundary. if ($pos & 0x7) { $pos += 7; $pos &= ~0x7;# Round to 8 byte boundary seek $f, $pos, 0; read $f,$rpm,16; } ($magic, $crap, $sections, $bytes) = unpack("N4", $rpm); die "Error: header not recognized\n" if $magic != 0x8eade801; $pos += 16;# for header $pos += 16 * $sections; $pos += $bytes; seek $f, $pos, 0; } if (eof($f)) { die "bogus RPM\n"; } open(ZCAT, "|gzip -cd") || die "can't pipe to gzip\n"; print STDERR "CPIO archive found!\n"; print ZCAT $rpm; while (read($f, ($_=''), 16384) > 0) { print ZCAT; } close ZCAT; After set up, rpm2cpio.pl works much like the C and Bourne shell versions, so the following command can be used to generate a cpio archive from an RPM package file: $ rpm2cpio.pl fluxbox-0.1.8-2.src.rpm | cpio -i -d CPIO archive found! 656 blocks $ Depending upon the system you are on, one or more of these three rpm2cpio programs should work. All three are useful any time you want to extract a file or files from an RPM package file but do not actually need to install the RPM. Summary Creating RPM spec files and maintaining those files can be a difficult chore. A number of tools and add-ons for text editors have sprung up to help make this less of a chore. Users of the two most common Linux text editors, vi and emacs, can use add-ons that understand the RPM spec file syntax. These add-ons help reduce errors and, though the use of macros, can speed development of spec files by automating some of the tasks. The RUST tool provides a graphical interface for creating spec files that can simplify a lot of the work normally required. Once you???ve created an RPM package, you can use the rpmlint command to flag missing, incomplete, or incorrect elements in your RPMs. Another tool, called rpm2cpio in its various incarnations, allows you to extract files from an RPM package by taking advantage of the fact that RPM files use the cpio format internally. The rpm2cpio tools can output RPM data into the cpio format directly; you can then pipe the output to the cpio command to extract. After all this help in making RPMs and spec files, the next chapter covers a set of best-practice guidelines to help avoid problems when making your RPMs. From fedora-docs-commits at redhat.com Tue Oct 4 01:52:30 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:52:30 -0400 Subject: rpm-guide rpm-guide-intro-packaging-en.xml,NONE,1.1 Message-ID: <200510040152.j941qV7M000611@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv593 Added Files: rpm-guide-intro-packaging-en.xml Log Message: --- NEW FILE rpm-guide-intro-packaging-en.xml --- Introducing Package Management Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Chapter *Issues in software management *Examining Linux management tools *Introducing the package concept In 1991, a young Finnish graduate student started a new personal hobby. He had acquired an Intel 386 computer and had spent a few weeks exploring it and playing early PC computer games. Eventually, however, he grew bored with the limitations of the MS-DOS environment that had come with his toy and decided that he wanted an operating system for it that he could use more productively. After exploring Minix, a feature-limited teaching operating system, he decided he needed a full-featured OS. At that time, no full-featured PC operating systems were freely available, so he decided to write his own operating system. Today, that small hobby OS that Linus Torvalds started almost as a whim has become Linux (www.linux.com), a significant new variant of Unix that runs millions of the world's network servers and, increasingly, desktop computers and embedded processors. Linux has grown up, successfully making the transition from a one-man personal project to a functional, full-featured operating system used by many of the world's major corporations and deployed on millions of corporate and personal systems. Along the way, Linux has had to address many of the same issues any new operating system must face. One of these concerns is how software for Linux, and how the Linux operating system itself, should be installed. How can administrators safely remove software packages without affecting other installed packages? And how can you safely upgrade packages? Answering these questions is what this book is all about. Installing, Removing, and Upgrading Applications Applications for most operating systems consist of multiple files that must be copied to specific locations on the computer's file system before each application can be run. This is true for common PC operating systems such as MS-DOS or Microsoft Windows, as well as for Unix and Linux. In the case of a Unix-like operating system such as Linux, other issues must also be considered. Unix and Linux are multiple-user systems, so they must track ownership of files. Furthermore, Unix and Linux use a system of file permissions. Administrators can grant some users access to files and can control how users may access those files, for example, allowing some users the permission to read only certain files. Administrators can deny other users access to the same files. So, installation of an application on Linux requires consideration of all these details. After files are copied into their appropriate locations, they must be granted correct permissions and correct ownerships. Similarly, administrators occasionally need to remove installed software from the computer. Maybe the program is no longer needed; maybe it does not work correctly for the needed task, or maybe the space it is using is needed for more important programs. In addition, installed software sometimes needs to be upgraded. Perhaps a new version of the software has come out and the currently installed version needs to be replaced with the presumably improved version. In most respects, software upgrades are the same as the removal of one application (the old version), followed by installation of another application (the new version). Upgrades do, however, have additional issues. Many applications must be configured before they can be used. Ideally, the upgrade for an installed application takes the current configuration into account, preserving old configuration information and applying it to the recently installed version. All these considerations make installation of a new application onto Unix or Linux a labor-intensive process. To further complicate matters, Unix applications have primarily been distributed as source code. To install a new application, such as the Apache Web server, you download the source code for that application???in this case, from the Apache Project's Web page (http://httpd.apache.org). Typically, the source code is provided in some sort of archive (such as the Zip archival and compression format often used in the Windows world or the tar archive format typically used in the Unix world) that you must then unpack. After unpacking this source code, you have to configure it to support the options and systems you want, compiling it to produce an executable program that can run on your particular operating system (CPU combination). After compiling the source code, you still have to install the application by putting all of its components (executable programs, documentation, configuration files, and so forth) into the correct locations on your hard drive and setting correct permissions on all those files. You might also need to perform other steps to prepare the system for the software. In the case of Apache, for example, some space needs to be set aside for storage of Web-access logs, and a special user account needs to be created so that the Apache Web server can operate more securely. Finally, you are ready to try running the application you have spent so much time installing. To help with all these tasks, precompiled software is becoming increasingly prevalent in the Unix and Linux communities, so you might be able to find executable (precompiled binary) copies of the application you wish to install that are appropriate for your particular machine's CPU. In that case, download an archive of the compiled application and unpack it. Then skip the compilation step, since that has already been done for you. The other steps required to install the package (copying files into correct locations, setting file permissions, and doing any needed system or application configuration) are exactly the same as the steps performed to install that application from source code. Once those steps are finished, you are ready to test your freshly installed application. When you run your newly installed application, you might be thrilled, perhaps discovering that it is something you want to use regularly. On the other hand, you might discover that you have no use for the software you have just installed, deciding that you want to uninstall it. Uninstallation occurs by reversing the installation steps. Remember any special steps you have performed (such as adding a user account), and undo those. Then remember all the files you have installed and where you have installed them. Manually delete them. As you can see, this can become a pretty tedious exercise. If you like the application you have installed, you will likely find yourself wanting to upgrade it eventually. The Apache Web server, for example, like any network service, must be upgraded whenever security problems are found and fixed. If you find that you need to upgrade Apache, you need to back up your Apache configuration files and then uninstall Apache. The next step is to install a new version of Apache, applying your Apache-configuration customizations to your new installation of Apache. All of this is a big pain. There has to be a better way. And there is. Overcoming the Installation Obstacles None of the tasks you must perform to install, upgrade, or uninstall applications are especially difficult. However, these steps quickly become daunting when you consider all the files that must be managed. A full Red Hat Linux 7.3 installation provides around 3,000 executable commands and over 160,000 total files (some other Linux distributions are even larger!). Obviously, managing all these files by hand, although theoretically possible, is not technically feasible. On a smaller scale, even management of single applications is not practical. The Postfix e-mail server application, for example, consists of around 275 files scattered in a dozen or so different directories. Imagine trying to remember and manually remove all of those files (and only those files) to uninstall Postfix from your system! All the steps needed to manage software on Unix or Linux systems are hardly unique to Unix; all operating systems have similar procedures that must be followed to make software usable on the system. For this reason, many approaches have been adopted toward software installation, uninstallation, and upgrading. Application-level utilities Some operating systems, such as MS-DOS, have supplied absolutely no built-in tools for software management. Installation of applications on such systems occurs in one of two ways: software is installed manually, using file-copy utilities to put all the application files in the appropriate places on the system, or software is installed using a custom-written installation application (as is usually the case for MS-DOS applications). Once installed, software can be uninstalled in one of two ways: you can manually delete each file installed for the application (assuming you can even remember them all), or the application might come with a custom uninstallation utility that can be run to remove the application. Upgrading an already installed application on such a system uses a similar procedure. If the application comes with an installation utility capable of handling application upgrades, you can use the utility to perform the upgrade. Otherwise, the software must be manually upgraded using the procedure described previously. Note Current versions of Windows, such as Windows XP, though, have a central database of installed applications. Built-in system utilities Other operating systems have come with built-in utilities that a system administrator can use to manage the system???s software. These utilities can be run to install the software on the system; typically, they take some of the work out of manually installing software, dealing with issues such as figuring out which files need to be put where on the system. Once installed, these utilities typically track the files that have been installed. This knowledge can usually be used to uninstall those applications automatically. Since the software knows which files are associated with the application, it can be told to uninstall the application, and it can find and delete all the files that belong to that application. These built-in utilities typically come in two different forms. One type focuses on managing the installation process, providing custom utilities that can be used to perform the otherwise manual tasks of compiling software and copying files into their final locations. The three major freely available Berkeley Unix, or BSD, operating systems, NetBSD, FreeBSD, and OpenBSD, for example, ship with a software-management system called, variously, ports (FreeBSD and OpenBSD) or packages (NetBSD). The ports system is composed of extensions to the normal Unix software-compilation utilities that help it automate and track many of the steps of a standard source-code compilation. When using ports, you still download source code, unarchive it, configure it, compile it, and install it, but the ports software automates many of these steps. Furthermore, the ports system does limited tracking of the files it installs. Although it does not offer more advanced features (such as an interface to search all installed files to see what application supplied that file) or the ability to upgrade installed applications, it does provide the ability to uninstall applications that are installed using ports. These sorts of limitations are typical of management applications that function as the ports system does, by enhancing the compilation and installation phases of application installation. The packages system on NetBSD has similar limitations. Other system-management utilities focus less attention on compiling an application for installation and more attention on the files that must be installed on the system after the application has been compiled. For example, the standard System V Unix package-management software supplied with most commercial Unix systems (Sun's Solaris, for example) devotes no attention to management of software compilation at all. Instead, it tracks the individual files associated with each application in a system database. To install software using the System V tools, you must compile the software. After compiling the software in the standard fashion, prepare a list of the files from that compilation that need to be installed on the system. Be certain to state where the files need to be installed and what permissions and ownerships they need to have once installed. Then run a series of commands that look at this list, find the files listed in it, and archive them into one file, along with a copy of this list that specifies where they should be installed and the ownerships and permissions. This single archive file can then be transferred to other machines, where a System V software-management command can be used to install it. This System V installation command (typically called pkgadd) unpacks the archive, copies the files into their final destinations based on the enclosed listing, and sets permissions and ownerships on the files as specified by the listing. Finally, this pkgadd command registers the list of freshly installed files into a system-wide database of installed files. Such a system offers several advantages over manual software installation. Software can now be installed and uninstalled easily, and the system-wide database of installed files can be readily searched to locate installed applications and files. However, this sort of system also has severe limitations; it is far less flexible in the software-configuration stages than software such as the FreeBSD ports system, which offers great control over the software-compilation stage of software installation. Linux Software Management Tools: Packages Initially, Linux had neither type of software-management tool. In the early days of Linux, you installed Linux by cross-compiling it under a different operating system (Minix), then manually installing the compiled Linux programs into the appropriate locations to produce a working system. As Linux has matured, however, it has acquired software-management tools that have made software installation, removal, and upgrade significantly easier than in the early days. The exact software-management tool used on modern Linux systems varies from distribution to distribution, but both approaches to system management can be found in the tools used by various distributions. The Gentoo Linux (www.gentoo.org) distribution, for example, uses a software-management system called Portage, which is very similar to the FreeBSD ports system. Like ports, Portage provides great control over software compilation and installation, providing a collection of scripts that automate much of the basic work of downloading and compiling software. At the other end of the spectrum, the now-defunct deepLinux distribution used a software-management system called deep-package (still available from www2.cddc.vt.edu/linux/distributions/deeplinux/tools. deep-package was intended to be a complete reimplementation of the Solaris pkgadd utility and its helpers. Like the Solaris pkgadd software, deep-package paid no attention to half of the question of how to manage software, focusing entirely on software installation and tracking issues while entirely ignoring the initial compilation of the software. More typically, however, Linux software-management tools use an approach somewhere between the two extremes represented by Portage and deep-package. Most Linux software-management tools provide software that manages the compilation of software, similarly to the FreeBSD ports tools. However, these software-management tools typically produce packages from the software they compile. Much like the archives produced by the System V software-management tools, packages are simply archive files that contain two things: a collection of related files, which together have a common use, and a script that provides all the metadata about those files necessary to install and manage those files. Typically, packages represent applications. For example, a Postfix package contains the 275 files that make up Postfix and a script that specifies where on the system those 275 files need to be placed, as well as what permissions and ownership those files need. A single command can then take this Postfix package file, extract its 275 archived files, and use the script to place those files correctly on the system. In addition, most Linux software-management tools have a database component that tracks files and applications that have been installed using the package-management software, helping the package manager do its job of easing the management of installed software. In the case of my full Red Hat Linux 7.3 installation, this package-management software maintains a database of information regarding all 160,000 files on the system; as applications are installed on the system, this database is updated with information regarding the new application and the locations of its component files. This database is the key component, making it possible to manage the system. Since this database remembers which 275 files compose the Postfix application, it ensures that I can uninstall Postfix with a single command that accesses this database, without my having to remember the locations of all 275 files that make up the Postfix application. A wide variety of software-management tools are available for Linux to help lessen the work involved with installing, removing, and upgrading applications installed on the system. This book focuses on one of these tools, the RPM Package Management software, or RPM. Note RPM was originally called Red Hat Package Manager. After adoption by other Linux distributions, the name has changed to simply the RPM Package Manager. The RPM initials remain the same. As the original name implies, RPM was developed by Red Hat, Inc., the major Linux distributor in the United States. Even though the original name seems to point to a Red Hat-only solution, most Linux distributions use the RPM software. The RPM software provides a foundation needed by Linux system administrators throughout the world. You can even use RPM on other operating systems, both Linux and non-Linux, as covered in Chapters 19 and 20, respectively. The RPM system provides all of the features needed to manage applications, including a database of installed packages with their version numbers, the ability to install, remove, and update packages, and the ability to recompile an application from a source code RPM package. The remaining chapters in Part I go into depth on what you can do with RPM packages and the commands you need to work with the RPM system: *Chapter 2 provides an overview of the RPM system, exploring what it was designed for and where it has weaknesses. *Chapter 3 discusses the technical details of how the RPM system works, where the database of packages gets stored, and what commands should be available for working with RPM packages. *Chapter 4 continues the discussion by covering the three major tasks you need to perform with RPM packages: installing software, removing software, and upgrading software you have already installed. *Chapter 5 covers the RPM database, how it works, where it resides, and how you can use it to better manage your system. *Chapter 6 delves into package dependencies, a very important concept. Most major applications depend on a number of other packages. Sometimes these dependencies get very complex, with one package depending on particular versions of other packages. With thousands of packages on your system, this can lead to a big mess. Chapter 6 helps you sort through the issues. *Chapter 7 covers the important issue of transactions, so that you can ensure your system gets updated in an orderly manner and so that you can roll back changes if something does not work out. *Chapter 8 introduces a host of tools that can help you find RPM packages as well as manage the packages on your system. This includes graphical interfaces on top of the RPM system and special Internet search sites devoted just to RPM packages. Later chapters cover creating RPM packages, programming with RPM, and extending the functionality provided by the base RPM system. Summary Modern operating systems have large complex sets of applications, resulting in thousands of files to keep track of for upgrades, installation, and removal of packages. All this complexity has lead Linux vendors to develop a variety of package-management tools. This chapter briefly introduced the RPM Package Manager, or RPM for short. The next chapter provides an overview of the RPM system, showing how all the parts fit together. From fedora-docs-commits at redhat.com Tue Oct 4 01:53:03 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:53:03 -0400 Subject: rpm-guide rpm-guide-intro-rpm-en.xml,NONE,1.1 Message-ID: <200510040153.j941r3i0000640@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv622 Added Files: rpm-guide-intro-rpm-en.xml Log Message: --- NEW FILE rpm-guide-intro-rpm-en.xml --- Introduction to RPM Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Chapter *Examining the history of package management *Introducing RPM features *Getting acquainted with RPM terminology Several package managers???software that tracks and manipulates the applications installed on the system???are available for Linux. The most widely used of these Linux package managers is the RPM Package Manager (formerly the Red Hat Package Manager), or RPM for short, the subject of this book Although RPM was initially developed for Red Hat Linux, a combination of technical features and good timing has resulted in RPM???s becoming the de facto standard for packaging software on most Linux distributions. The fact that Red Hat released the source code to the RPM software under an open-source license also helped its adoption. More recently, the RPM package file format has been adopted as the official standard for Linux as part of the Linux Standards Base, or LSB. Described at www.linuxbase.org/, the Linux Standards Base is an attempt to set a baseline that all Linux distributions should follow. Some vendors have been pulled in kicking and screaming, but the LSB for the most part has really helped the job of system administrators by providing some commonality across distributions, as in the location of certain files. The history of Linux package managers is largely intertwined with the history of Linux distributions. Strictly speaking, Linux refers to a single piece of software, the Unix-like kernel that Linus Torvalds and cohorts have scattered all over the Internet and have been developing since 1991. This Linux kernel is a marvelous piece of software, currently comprising over 3.7 million lines of freely-licensed source code and accompanying documentation. Together, these factors provide a fast, full-featured, stable operating system kernel for use on more than 30 different processor architectures, ranging from embedded systems such as watches and PDAs, to desktop and server systems, all the way up to mainframes and supercomputing clusters. The Need for Linux Package Management Systems Although Linux is an excellent core component of an operating system suitable for a wide variety of real-world applications, this Linux kernel by itself is not sufficient for accomplishing most tasks. The technical definition of exactly what constitutes an operating system is a matter of debate. Despite this controversy, it is clear that most users of Linux require both the Linux kernel and a large suite of accompanying software (a shared C library; traditional Unix utilities such as grep, awk, and sed; an editor, such as vi; a shell, such as the Bourne-Again "bash" shell; and so forth) to complete the various tasks for which they typically employ Linux. Users expect Linux to include server software such as the Apache Web server, desktop software such as the OpenOffice.org office productivity suite, and a host of other packages. In fact, most Linux users don???t make the distinction between the kernel (technically the only part that is ???Linux???) and all the extra packages (technically ???everything else???) that comes with a Linux distribution. Most users simply refer to the whole thing as ???Linux.??? Some Linux distributions include thousands of packages on six or more CD-ROMs. This situation alone cries out for effective package-management software. And this doesn???t include the extra packages that don???t come with Linux distributions but which organizations need to create an effective working environment. Furthermore, the Linux kernel and these various software applications are typically made available by their developers in source code formats only, and they can be installed manually only after compiling them from source code. Most people do not have the technical skills necessary to cross-compile an entire operating system. Even if they do, they usually do not want to devote the time and effort required to bootstrap and compile an operating system just to be able to run Linux. Fortunately, the early Linux programmers quickly realized the impracticality of source-code only releases early in Linux's development and created what they called distributions???collections of precompiled binaries of the Linux kernel and other necessary software that users often wanted. Rather than installing Minix, compiling the Linux kernel and other required software applications under Minix, and installing those compiled binaries of the Linux kernel and essential Linux applications, users could just install these distributions, immediately having a functional Linux environment in which to work. Early distributions, such as MCC and SLS, initially represented little more than archived snapshots of their developer's hard drive. They offered the user performing the installation little or no control over what applications were put on the system. Whatever the distribution developer had on his hard drive was what the distribution installer got on her hard drive. Even this was much better than rolling your own distribution by hand. SLS, for example, stood for Soft Landing System, and was designed to make the experience of installing Linux easier, hence providing a ???soft landing.??? MCC Interim Linux, from the Manchester Computing Centre, was the first distribution to sport a combined boot/root disk, another attempt to make life easier for those adopting Linux. Distribution developers quickly realized, however, that more flexibility was needed and began looking for ways to provide choices both during and after installation. The Slackware distribution, for example, divided applications into several functional categories. All users installed the base distribution; users could then selectively install only the additional supplemental categories they needed. If networking support was desired, for example, the networking bundle could be installed. Similarly, if a graphical user interface was desired, the X bundle could be installed, making the X Window System available. This concept offered rudimentary control over what was installed but only at a very coarse level. Installing the X bundle put several applications (multiple X terminal emulators, several different window managers, and so forth) on the system, and all users who installed the bundle got all of those applications whether they wanted them all or not. The next logical step in distribution evolution was the development of more advanced tools to control what was installed. Several distributions independently developed the notion of application-level installation management. The developers of these distributions realized that Slackware and similar distributions were heading in the right direction, but simply had not made software management granular enough. Slackware allowed installation and uninstallation (after a fashion) of bundles of related applications, but what was really needed was installation and uninstallation on an application-by-application basis. In late 1993, Rik Faith, Doug Hoffman, and Kevin Martin began releasing the first public betas of the BOGUS Linux distribution. BOGUS was notable for the package management system (pms) software that was used with it for installation and uninstallation of all software on an application-by-application basis. Shortly thereafter, in the summer of 1994, the first public betas of Red Hat Commercial Linux were released. Red Hat initially used Red Hat Software Program Packages (RPP) as the basis of its Linux distribution. Like pms, RPP was a system-management tool that allowed for easy installation and uninstallation of applications. In late 1993, Ian Murdock founded the Debian Gnu/Linux distribution. He began seriously developing its dpkg application-management software by the summer of 1994. Like pms and RPP, dpkg made it possible to manage each application on the system. RPM Design Goals All of these early system-management tools took a similar approach. They provided the capability to install an entire application with a single command, to track the files it put on the system, and to remove those files by using another single command. As the preponderance of multiple early tools suggests, this approach to system management was popular. All of these early tools, however, had numerous technical or practical deficiencies. Some tools were designed only for Linux on 32-bit Intel-compatible hardware, even though Linux by this point was already running on other CPUs in addition to the IA32 family. As Linux was spreading to multiple architectures, a package-management system that could produce packages for multiple architectures was needed. Other tools had technical flaws in how they prepared packages, making it difficult to verify that packages had been prepared correctly or to see exactly how the software was prepared. Because of these concerns, after their initial releases of RPP-based distributions, Red Hat looked closely at both their own RPP software and other software such as BOGUS's pms software. Developers at Red Hat, particularly Marc Ewing and Erik Troan, set out to develop what they initially called the Red Hat Package Manager (RPM). Based on experiences with earlier Linux packaging software and knowledge about packaging tools used on other platforms, Red Hat had several design goals in mind when they developed RPM. These design points include the following features: *Ease of use *Package-oriented focus *Upgradability of packages *Tracking of package interdependencies *Query capabilities *Verification *Support for multiple architectures *Use of pristine sources The following sections demonstrate how Red Hat incorporated each of these design goals into RPM. Ease of use Perhaps the primary design goal for RPM is that it must be easy to use. Manual software installation has been the primary method of putting software onto Unix boxes for over 30 years now and has worked very well for those three decades. To offer a compelling reason to use the new software, Red Hat's RPM must be significantly easier to use than other Linux package-management tools. For that reason, most tasks that can be handled using RPM were designed to be carried out via a single command. For example, software installation using RPM requires a single command (rpm -U software_package), while manual software installation using older manual methods typically requires at least six steps to complete the same task: 1.tar zxf software_package 2.cd software_package 3../configure 4.make 5.su 6.make install Similarly, removal of applications installed using RPM requires a single command (rpm -e software_package); manual removal of an installed application requires that each file associated with that application be manually deleted. Package-oriented focus Like its predecessors, RPM is intended to operate on a package level. Rather than operating on a single-file basis (as when you manually install software using Unix command-line tools like mv and cp) or on an entire system basis (as with many PC operating systems, which provide the ability to upgrade entire releases but not to upgrade individual components), RPM provides software that can manage hundreds or thousands of packages. Each package is a discrete bundle of related files and associated documentation and configuration information; typically, each package is a separate application. By focusing on the package as the managed unit, RPM makes installation and deletion of applications extremely straightforward. Package upgradability In addition to its package-oriented focus, RPM is designed to support upgrading packages. Once an application has been installed from an RPM package, a newer version of the same application can be installed using RPM. Doing so upgrades the existing application, removing its old files and replacing them with new files. In addition, however, RPM takes care to preserve any customizations that have been made to that application. The Apache Web server application, for example, is commonly installed on Linux machines that need the ability to serve Web pages. Apache's configuration information, which specifies things such as which files on the system should be made available as Web pages and who should be able to access those Web pages, is stored in a text file, typically /etc/httpd/conf/httpd.conf. Suppose Apache has been installed using RPM and that you have then customized httpd.conf to specify its configuration. If you upgrade Apache using RPM, as part of the upgrade procedure, the RPM application will take precautions to preserve the customizations you have made to the Apache configuration. In contrast, manual upgrades of applications often overwrite any existing configuration files, losing all site customizations the system administrator has made. Package interdependencies Software that manages the applications installed on the system on an application level (such as RPM) does have one potential drawback in comparison with system-wide software management systems (such as PC operating systems like Microsoft's Windows or IBM's OS/2, which allow the entire system to be upgraded but do not generally allow individual components to be upgraded, added, or removed). Software applications often have interdependencies; some applications work only when other applications are installed. The Postfix and Sendmail mail transfer agent (MTA) applications that are commonly used on Linux boxes to serve e-mail, for example, can both be configured to require users to authenticate themselves (by submitting a correct user name and password) successfully before they can use the e-mail server. This feature is often used to prevent unauthorized access to the e-mail server, preventing unscrupulous advertisers from using the server as a tool to send unsolicited commercial e-mail (or UCE, popularly known as spam). For this optional feature of Postfix and Sendmail to work, however, additional software must be installed. Both applications use another application, Cyrus SASL, which provides the Simple Authentication and Security Layer (SASL) software that Postfix or Sendmail can use to check user names and passwords. In other words, Postfix and Sendmail depend on Cyrus SASL. For system-wide software management systems, logical interdependencies between system components such as these are easy to track. All required components are included as part of the system, and upgrading the system upgrades all these components, ensuring that all can still interoperate. On Microsoft Windows 2000, IIS (the application used on Windows to serve Web pages) requires several other applications such as EventLog (the Windows application that records system events, much like the Linux syslogd and klogd software) to be present. Since Windows is managed on a system level, not a package level, this dependency is guaranteed to be satisfied. On Linux systems using RPM, however, the situation is different. On Linux, for example, the Postfix application requires the syslogd application, which records system events. However, RPM provides the flexibility to install some applications but not install others or to uninstall others later. When you install Postfix, you have no guarantee that syslogd is already installed. If syslogd is not installed, Postfix will not work correctly. To avoid problems, Red Hat developers realized that RPMs must also track dependency information about what software they require for correct functionality, and that the RPM install and uninstall applications must use this dependency information. Because of dependencies, installing Postfix using RPM on a system without syslogd installed generates a warning that syslogd must also be installed. Similarly, attempting to uninstall syslogd from a system that already has Postfix installed generates a warning that installed applications require the software that is being deleted. These warnings can be overridden if necessary, but by default RPM enforces these dependencies (refusing, for example, to let you uninstall syslogd without also uninstalling applications that require it, such as Postfix), preventing you from accidentally breaking applications by inadvertently uninstalling other software that they require to operate. Query capabilities As part of its implementation, the RPM software maintains a database on the system of all packages that have been installed, and documenting which files those packages have installed on the system. RPM is designed to be queried easily, making it possible for you to search this database to determine what applications have been installed on the system and to see which packages have supplied each file on the system. This feature makes RPM-based systems extremely easy to use, since a single RPM command can be used to view all installed applications on the system. Package verification RPM also maintains a variety of information about each installed file in this system database, such as what permissions each file should have and what size each file should be. Red Hat developers designed this database to be useful for software verification. Over time, installed software will fail to work for reasons as mundane as the system administrator setting incorrect permissions on files or as exotic as nuclear decay of one of the computer's atoms releasing an alpha particle that can affect the computer's memory, corrupting that bit of memory and causing errors. Although RPM cannot prevent all errors that cause installed software to fail (obviously, there's not a single thing any software can do to prevent nuclear decay), it can be used to eliminate common errors. When an application fails, you can use the RPM database to make sure that all files associated with that application still have correct Unix file permissions and that no files associated with that application have become altered or corrupted. Multiple architectures Most of the RPM design goals mentioned so far are intended primarily to ease the life of system administrators and others who regularly install, remove, and upgrade applications or who need to see what is installed or verify that installed applications have been installed correctly. Some of the design goals for RPM are intended primarily not for those sorts of users of RPM but for users who must prepare software to be installed using RPM. One of the major limitations of early Linux package management utilities was that they could produce packages suitable only for installation on one type of computer: those that used 32-bit Intel-compatible CPUs. By 1994, Linux was beginning to support other CPUs in addition to the originally supported Intel CPUs. (Initially, Digital's Alpha processor and Motorola's 68000 series of processors were among the first additional CPUs that Linux supported. These days, Linux supports dozens of CPU architectures.) This posed a problem for distribution developers such as Red Hat and Debian and for application vendors who desired to package their software for use on Linux. Because the available packaging methods could not produce packages for multiple architectures, packagers making software for multiple CPUs had to do extra work to prepare their packages. Furthermore, once the packagers had prepared packages, no method was available to indicate the architecture the packages targeted, making it difficult for end users to know on which machine types they could install the packages. Red Hat decided to overcome these limitations by incorporating architecture support into RPM, adding features so that the basic setup a packager performs to create a package could be leveraged to produce packages that would run on various CPUs, and so that end users could look at a package and immediately identify for which types of systems it was intended. Pristine sources The BOGUS distribution's pms packaging system introduced the use of pristine source code to prepare packages. With Red Hat's early RPP package system and other similar early efforts, software packagers would compile software manually, then run commands to produce a package of that compiled software. Any changes made to the application's original source code were not recorded and would have to be recreated by the next person to package that software. Furthermore, end users wanting to know what changes had been made to the software they were running had no method of accessing that information. With RPM, Red Hat developed a package system that produced two types of packages: binary and source. Binary packages are compiled software that can be installed and used. Source packages contain the source code for that software, along with a file documenting how that source code must be compiled to produce that binary package. This feature is probably the single most significant difference between modern Linux packaging software (such as RPM) and the packaging software used on other systems (such as the pkg format that commercial Unix systems use). Source packaging makes the job of software packager easier, since packagers can use old source packages as a reference when preparing new versions of those packages. Source packages are also convenient for the end user, because they make it easily possible to change options with which that software was compiled and to produce a new binary package that supports the features the user needs. RPM Terminology When working with RPM, understanding the package concept is key. RPM packages are provided as compressed archive files that contain one or more files, as well as instructions specifying installation information about those files, including the ownerships and permissions that should be applied to each file during installation. The instructions can also contain scripts to be run after installation or before uninstallation. These package files are extremely convenient; they provide a single file that can be easily transferred between machines for installation rather than having to transfer each file to be installed. To help in installation and management, all package files are labeled with highly identifiable names. Red Hat Linux package files have four-part names, which typically look something like: kernel-smp-2.4.18-3.athlon.rpm kernel-smp-2.4.18-3.i586.rpm kernel-smp-2.4.18-3.i686.rpm kernel-source-2.4.18-3.i386.rpm rootfiles-7.2-1.noarch.rpm Here, the four parts of each name are separated from each other by dashes or periods. The structure of the package file name is name-version-release.architecture.rpm The name identifies what software is contained within the archive file. Typically, this is a name of an application or package that the archive installs on the system. For example, kernel-smp can be installed to provide a very important application, the SMP (symmetric multiprocessing, meaning it supports systems with more than one CPU in them) version of the Linux kernel, on the system. Sometimes, rather than an application, the software is a collection of other files needed on the system. The rootfiles package, for example, is not an application but is a collection of basic environmental configuration files for the root user's account (such as /root/.bashrc, the root user's Bash configuration file) that provides a usable, preconfigured working environment for the root user on Red Hat Linux systems. The second field in every Red Hat Linux package file's name is the version field. This field identifies the version number of the software that is contained in the package file. For example, kernel-smp-2.4.18 indicates the RPM holds the 2.4.18 release of the SMP version of the Linux kernel, and rootfiles-7.2 is the 7.2 release of the rootfiles configuration files. Every Red Hat Linux package file name also has a third component: the release field. This field identifies which release of that version of the software the package file contains. Package files contain both software and instructions about how to install that software. As packages of a particular version of software are being prepared, mistakes are sometimes made in these instruction files, or bugs are sometimes fixed within a software version; more recent package files of that software version need to be prepared that correct the problem. The ???1 in the rootfiles-7.2-1 package shows this is the first release of the 7.2 version of the rootfiles software. The packager of rootfiles version 7.2 got everything right on the first try and had no need to prepare more than one release. The ???3 in the kernel-smp-2.4.18-3 package, on the other hand, is the third release of the 2.4.18 version of the SMP-capable Linux kernel. This release incorporates new patches to fix bugs present in older releases of the 2.4.18 version of the Linux SMP kernel. The software packager increased the release number so that end users could distinguish the more recent, bug-fixed package file from the older, less bug-free package file. The final field in Red Hat Linux package file names is the architecture, which identifies the system types for which the package file is appropriate. For example, the kernel-smp-2.4.18-3.athlon package is intended for use on machines with an AMD Athlon CPU, and kernel-smp-2.4.18-3.i586 is intended for use on machines with an i586 (Pentium-class) CPU or better. An architecture name of noarch indicates this is a special architecture such that the files in the package work on any architecture. Typically, this is because the files are all interpreted scripts, not binary executables, or are documentation. RPM supports various architectures. Table 2-1 presents the architectures available for different platforms as of RPM version 4.1. Table 2-1Supported Architectures Platform Architectures Intel compatible 32-bit i386, i486, i586, i686, athlon Intel compatible 64-bit ia64 HPAlpha (formerly Digital, Compaq) alpha, alphaev5, alphaev56, alphapca56, alphaev6, alphaev67 Sparc/Ultra Sparc (Sun) sparc, sparcv9, sparc64 ARM armv3l, armv4b, armv4l MIPS mips, mipsel Power PC ppc, ppciseries, ppcpseries, ppc64 Motorola 68000 series m68k, m68kmint SGI MIPS Sgi IBM RS6000 rs6000 IBM S/390 i370, s390x, s390 Platform independent noarch Tip When choosing an appropriate architecture for your machine, be aware that more recent architectures typically run software that targets older architectures within the same family; the reverse, however, is not true. For example, within the 32-bit Intel-compatible architectures, a 686-class (Pentium II / III / IV) machine runs files within i386, i486, i586, and i686 RPM package files, but a 386-class (80386) machine runs files within i386 RPM package files only. Similarly, for the Alpha architecture, more recent Alpha EV68 CPUs can run programs from RPM package files with alphaev67, alphaev6, alphaev56, alphaev5, and alpha architectures, but an older Alpha EV56 machine can run programs from RPM package files with alpha, alphaev5, or alphaev56 architectures only. Notice that the four fields in RPM package file names are separated from each other by punctuation, either a dash (-) or a period (.). Periods and dashes, however, are also allowed within fields. 7.2 is a valid version number, just as kernel-source is a valid software name. Finally, keep in mind that all RPM package files use an .rpm file-name extension to denote that they are RPMs. Once installed, package names are slightly different from package file names. Package files, which can be downloaded from the Internet, copied off of CDs, and otherwise easily transferred between machines, always have names that looks like name-version-release.architecture.rpm. Installed packages, however, have names that look like name-version-release. Once installed, packages are referred to without the architecture field and the .rpm extension. Furthermore, installed packages consist of lots of files, not a single RPM file. For example, the package file kernel-smp-2.4.18-3.i686.rpm after installation is referred to as kernel-smp-2.4.18-3. To simplify usage even further, installed packages can be referred to by their name field only, so this file would become simply kernel-smp. Warning Once installed, the name of the package does not have to be the same as the name portion of the original package file. By convention though, the package name matches the name, version, and release part of the file name. Usage of the name field by itself to name packages assumes that multiple versions or releases of that particular software are not installed. However, it is in some cases necessary to install different versions or releases of the same package. My desktop at home is a (by now, relatively old) dual Pentium-II system, so it uses an SMP-capable Linux kernel. On it, I have the following Linux SMP kernels installed: $ rpm -q kernel-smp kernel-smp-2.4.18-4 kernel-smp-2.4.18-3 kernel-smp-2.5.21-4 $ This example uses the rpm ???q command to query for all installed versions of the given package, kernel-smp. Cross Reference Chapter 5 covers querying the RPM database in depth. I have two different package file releases (release 3 and release 4) of the 2.4.18 version of the Linux kernel, and I have a development kernel, version 2.5.21, installed. On this system, since I have multiple packages installed of the kernel-smp software, I have to use the full package name (such as kernel-smp-2.4.18-4) whenever I want to work with my installed kernel-smp packages. Summary The RPM system wasn???t created to solve some theoretical problem. Instead, it is the result of years of hard-won practical experience in trying to manage systems with a large number of applications. RPM builds upon older systems that were created to solve some of the problems faced by system administrators. RPM goes further, though, and tries to provide a complete package-management solution. This includes the ability to deal with wrinkles that Linux faces but that many other operating systems do not need to address. For example, most other operating systems don???t support more than one or two processor architectures. Sun???s Solaris, for example, supports only the SPARC and Intel architectures. Linux supports these and more. Most other operating systems also don???t include nearly so many applications. From the OpenOffice.org office suite to the Apache Web server, Linux distributions are literally packed with applications. As a final point, most other operating systems provide mostly closed-source applications. Linux, on the other hand, includes thousands of open-source applications. From the perspective of the organizations making Linux distributions, these wrinkles make Linux harder to manage. Luckily for end users, the solution to these problems helps make the RPM system better able to manage user systems: *The RPM system tags each package with the processor architecture and allows for multiple versions of the same package to be installed on the same system. RPM also packs all the files in a package into one file, called an RPM file, for easy transfer to other systems. *Most RPM operations such as installing or removing packages require only a single command to run. *The RPM system supports building RPM packages from a pristine set of sources. This means you can reproduce the commands required to build an application, improving quality. This chapter introduced the RPM system and the history behind it. The next chapter delves into the RPM basics, including files, database, and commands. From fedora-docs-commits at redhat.com Tue Oct 4 01:53:35 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:53:35 -0400 Subject: rpm-guide rpm-guide-licensing-en.xml,NONE,1.1 Message-ID: <200510040153.j941rZfS000669@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv651 Added Files: rpm-guide-licensing-en.xml Log Message: --- NEW FILE rpm-guide-licensing-en.xml --- Licensing RPM Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). When incorporating someone else's existing code into your software project, you should always examine the license of the code carefully, make sure you understand its implications, and make sure you are willing to abide by them. You also need to make sure you have the legal right to incorporate the other code in your project. This is true for commercial code and commercial projects, and it is equally true for freely licensed code and free software projects. RPM itself and most discussed helper applications (rpmlint, rpm-spec-mode, and so forth) are free software, meaning that the programs themselves are available without cost. In addition, most of these tools are considered open source software, which means the source code for the applications are also available. These facts do not mean that they are unlicensed software, or that their source code can be used in any desired fashion. RPM and these helper applications are made freely available in both source and binary formats under the terms of the GNU Project's General Public License (GPL). Parts of RPM are licensed under the LGPL, the Lesser General Public License. The terms of the GPL are reproduced here, and should be consulted before incorporating any source code or binaries licensed under the GPL into your projects. Essentially, the GPL states that you can use GPL'ed source code or binaries for any purpose, so long as you always give those same rights (including access to your program???s source code) to any users to whom you give software derived from GPL'ed source code (though a lawyer should be consulted to obtain an analysis of the implications of the GPL on your project, should you decide to use GPL'ed code in any commercially licensed project you might undertake). The GNU General Public License Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 675 Mass Ave, Cambridge, MA 02139, USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0.This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 1.You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2.You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a)You must cause the modified files to carry prominent notice stating that you changed the files and the date of any change. b)You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c)If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3.You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a)Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b)Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c)Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 4.You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 5.You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 6.Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 7.If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 8.If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 9.The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 10.If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 11.BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 12.IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS Appendix: How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. <one line to give the program's name and a brief idea of what it does.> Copyright (C) 19yy <name of author> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. Also add information on how to contact you by electronic and paper mail. If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) 19yy name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. <signature of Ty Coon>, 1 April 1989Ty Coon, President of Vice This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License. From fedora-docs-commits at redhat.com Tue Oct 4 01:54:12 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:54:12 -0400 Subject: rpm-guide rpm-guide-management-software-en.xml,NONE,1.1 Message-ID: <200510040154.j941sCMU000704@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv681 Added Files: rpm-guide-management-software-en.xml Log Message: --- NEW FILE rpm-guide-management-software-en.xml --- RPM Management Software Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Chapter *Finding packages in RPM format *Graphical tools to manage RPM packages *Extending RPM management with additional tools You can find a variety of software packages to ease the work of managing RPM-based systems. These utilities can help you find a specific software application packaged using RPM or search through a collection of RPM-packaged software to locate applications with specific features. Similarly, several utilities provide features to ease long-term system-management tasks. These applications provide features such as automatic updating of existing installed software with more recent versions or simplification of software installation by automating installation of any required software dependencies. This chapter covers a number of tools for finding packages in RPM format, as well as tools to help manage the RPMs on your system. Locating RPMs RPM provides a powerful tool for managing software installed on a system. With a single command, an entire application can be installed on the system in a ready-to-run configuration. With a different command, the entire application can be removed without having manually to track down all of the associated files scattered throughout the hard drive. For RPM to work, however, the software being managed must be packaged in the proper RPM format. RPM packages can be easily prepared if necessary, but you can save time by using the wide variety of software already available in the RPM format. The only trick to using this RPM-packaged software is finding it. As you start to search for RPM packages on the Internet, you???ll find thousands of packages available. Many of these packages are built specifically for various Linux distributions, such as Conectiva, SuSE, Red Hat, or Mandrake. In many cases, the Linux distribution won???t matter, but in general it's best to download packages built for your version of Linux, such as Red Hat. Note Although the examples in this book assume Red Hat Linux as a base, just about everything applies to all versions of Linux that use the RPM system, unless noted otherwise. Internet search engines are popular, but they aren???t very helpful for finding RPM packages, especially because lots of Web pages have the term rpm (including those covering revolutions per minute). A more efficient approach is to use one of the RPM-specific Internet search tools such as rpmfind. rpmfind and rpm2html One popular free tool for locating RPMs is rpmfind, written by Daniel Veillard. This tool provides a command-line utility that can search for packages by name or description, displaying or optionally downloading any matching packages it finds. It can even provide a list of the dependencies that those matching packages require to run and can download those required dependencies as well. When searching for packages, rpmfind can search both the software already installed on the local system and remote databases, including the databases located at http://rpmfind.net/. Note The databases at http://rpmfind.net/ are, in turn, created by another utility: rpm2html. Both are covered in the sections following. Commonly, rpmfind is used to search for packages by name, though it can be used to search package descriptions for key words. For example, I might want to find new e-mail clients to install on my system. I happen to know that one popular Linux e-mail client is Ximian???s evolution, so I search for that. The basic syntax for rpmfind follows: rpmfind package_name For example, to search for evolution, use a command like the following: $ rpmfind evolution Resource evolution already installed $ Before accessing the Internet, rpmfind searches my local system and finds that I already have evolution installed, so it does not even bother searching for copies to download. It looks like I???m forgetful, not remembering that I already have evolution installed. At this point, I might realize that I already have the software I need, or I might decide to search for a similar application, such as exmh, another popular Unix e-mail client. To search for exmh (which in this example has not been installed), use a command like the following: $ rpmfind exmh Installing exmh will require 7301 KBytes ### To Transfer: ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS//nmh-1.0.4-9.i3 86.rpm ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS//exmh-2.4-2.noarch.rpm Do you want to download these files to /tmp [Y/n/a/i] ? : a transferring ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS//nmh-1.0.4-9.i386.rpm saving to /tmp/nmh-1.0.4-9.i386.rpm transferring ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS//exmh-2.4-2.noarch.rpm saving to /tmp/exmh-2.4-2.noarch.rpm rpm -U /tmp/nmh-1.0.4-9.i386.rpm /tmp/exmh-2.4-2.noarch.rpm $ Here, rpmfind searches my local system for exmh. Since exmh is not installed there, rpmfind searches the databases at http://rpmfind.net/ and does two things: it finds exmh, and it learns that exmh depends upon another package: nmh. After [...1729 lines suppressed...] this reason, apt can only be used to update systems from apt-capable repositories. Although apt was created by the Debian Project and designed for dpkg-format software packages, nothing about apt requires that it inherently be usable only with dpkg-format packages. Because of this, and because of its powerful capabilities, Conectiva, a Brazilian Linux distribution vendor (www.conectiva.com), extended apt to support management of RPM packages in addition to dpkg packages. Conectiva???s work, commonly referred to as apt-rpm, makes the apt client software available for use on any RPM-based Linux distribution. Conectiva also provides its customers with access to apt-capable FTP servers. A related project, apt4rpm (http://apt4rpm.sourceforge.net/), supplies the necessary utilities that can be used to make any RPM repository apt-capable. By creating apt-capable servers using apt4rpm and then installing apt-rpm on the client systems, any RPM-based distribution, such as Red Hat Linux, Mandrake Linux, Caldera/SCO OpenLinux, or SuSE Linux, can then be easily managed using apt. Note The freshrpms.net site, mentioned previously, provides a touted apt repository. Administrators managing multiple dispersed machines as well as those used to Debian administration often find it useful to configure their machines to use apt; its dependency tracking is far better than any other tool, except for Red Hat???s up2date/RHN combination. To use apt, administrators must install it on their machines and have access to an apt-capable RPM repository for the distribution they use. Several public FTP sites that support apt are now available for most of the major RPM-based distributions. Also, the administrator can create another apt-capable repository. Configuration of machines to use apt is simple. The apt and libapt RPMs simply need to be installed. Although binaries are sometimes available, the best success can usually be obtained by building binary RPMs from the latest Conectiva apt SRPM (source RPM), available at ftp://ftp.conectiva.com/pub/conectiva/EXPERIMENTAL/apt/. Once apt and libapt RPMs are installed, the sources.list file in /etc/apt needs to be modified to reference the apt-capable software site that will be used. For example, to configure a machine to access the apt-capable Red Hat Linux 7.2 software distributed by the Tuxfamily.org server, the /etc/apt/sources.list file needs to list: rpm http://apt-rpm.tuxfamily.org/apt redhat-7.2-i386/redhat os rpm http://apt-rpm.tuxfamily.org/apt redhat-updates-7.2/redhat os These two lines, respectively, access the Red Hat Linux 7.2 and Red Hat Linux 7.2 errata RPMs being served by the system apt-rpm.tuxfamily.org. If you also want access to source RPMs, the following lines are necessary as well. rpm-src http://apt-rpm.tuxfamily.org/apt redhat-7.2-i386/redhat os rpm-src http://apt-rpm.tuxfamily.org/apt redhat-updates-7.2/redhat os In addition to, or instead of, using public apt-capable servers, many sites want to create their own apt servers. If apt is being used to manage all the machines in the enterprise, a custom apt server might be needed that contains apt-accessible RPMs of all the custom software used in the enterprise. This can be done using the tools provided by the apt4rpm package (http://apt4rpm.sourceforge.net). Once apt has been installed on clients, and the clients have been configured to access an apt-capable server, keeping systems updated is simple. The command apt-get update updates the client system???s apt database of available software, after which the command apt-get upgrade upgrades all currently installed software to the latest version available in the software repository. By listing a site that provides vendor errata updates in /etc/apt/sources.list and then setting up a nightly cron job to run the apt-get upgrade command, administrators can be sure that client systems always have the latest errata installed. You can use a similar technique to ensure that all client systems are always up to date with the latest custom in-house applications. To do this, set up your own apt server and ensure that the latest custom applications are placed on the apt server. In addition, apt simplifies interactive installation of RPMs on systems that are using it. The command apt-get install package retrieves the named RPM from the apt-capable software repository and installs it. If the package requires any dependencies that are not already resolved, apt will ask for confirmation, then download and install the package and all dependencies. Similarly, apt-get remove package uninstalls the named RPM. If any other packages depend on it, it will prompt for confirmation, then uninstall the named RPM and all of its dependencies. In addition to these command-line utilities, several graphical front-end tools for manipulating apt are currently being ported for use with apt-rpm. Because of its ease of use for automating installation of system errata and necessary custom software, and because of the excellent dependency tracking it provides for interactive installation and uninstallation of software, apt-rpm can be excellent for managing RPM-based systems. The poldek Also similar to the Debian apt tool, a utility called the poldek works like apt-get. The poldek was designed to quickly scan through dependencies and install a number of packages at once. You can specify all the packages to install in a file. The poldek automatically downloads any needed dependencies. The poldek can download files over the Internet and also help create the packages for storage on CD-ROMs. The poldek optimizes the set of packages to reduce the number of times users have to switch CDs. Cross Reference For more on the poldek, see poldek.pld.org.pl. Summary This chapter has covered a number of tools for finding packages in RPM format, as well as tools to help manage the RPMs on your system. The rpm command does a great job of installing, removing, and upgrading packages. You can use it or choose from one of the many graphical RPM management tools shown in this chapter. The rpmfind utility helps find RPM packages on Internet servers. You can use rpmfind to find the latest version of the packages installed on your system. The Nautilus file manager allows you to browse files on disk, and it installs any RPM files you double-click. Red Hat Linux 8 comes with a new package-management tool available from the System Settings menu. Be careful with this tool, though, as it automatically installs--and removes--dependent packages. AutoRPM and AutoUpdate provide utilites that you can run periodically to ensure that your systems are up to date. The Red Hat Network and up2date also provides this capability. The Debian GNU/Linux apt system provides many of the same capabilities as RPM, along with the network-updating capabilities of up2date and the Red Hat Network. You can use special apt packages that adapt apt for RPM-based Linux distributions and get the best of both the RPM system and the apt system. The next chapter starts the major section on creating RPMs. The RPM system reduces a lot of the burden of administering Linux systems. You can take advantage of this when building any sort of software for distribution--or even when managing your own system. From fedora-docs-commits at redhat.com Tue Oct 4 01:54:41 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:54:41 -0400 Subject: rpm-guide rpm-guide-online-resources-en.xml,NONE,1.1 Message-ID: <200510040154.j941sfvH000733@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv715 Added Files: rpm-guide-online-resources-en.xml Log Message: --- NEW FILE rpm-guide-online-resources-en.xml --- RPM Resources Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Appendix *Finding RPM sites on the Internet *Accessing RPM newsgroups and mailing lists This appendix covers the material available on the Internet for working with RPM. Finding RPM Sites There is a wealth of RPM material online, although some of it is hard to find. The following sections list a number of RPM-related sites, divided by category. Note that as with any Internet sites, the sites listed my change or disappear. The main rpm.org site The main RPM site is www.rpm.org. This site provides the official distributions of the RPM software, as well as a lot of documentation online. Table F-1 lists a number of useful links on this site. Table F-1 Links on the rpm.org site Link Holds ftp://ftp.rpm.org/pub/rpm/dist/ RPM software downloads ftp://ftp.rpm.org/pub/ rpm.org download site www.rpm.org/cvs_help/ Instructions for accessing the RPM CVS repository www.rpm.org/hintskinks/ Tips for working with RPM www.rpm.org/hintskinks/bootstrap/ Good tips on bootstrapping RPM to new platforms www.rpm.org/howto/ How-to documents for working with RPM www.rpm.org/max-rpm/ Maximum RPM by Edward C. Bailey www.rpm.org/RPM-HOWTO/ Good introductory tutorial www.rpm.org/rpmapi-4.1/ API documentation The main RPM FTP site, at ftp://ftp.rpm.org/pub/, includes the RPM distributions, as well as the Berkeley DB version 3 library, and the text of the book Maximum RPM. Download RPM software from ftp://ftp.rpm.org/pub/rpm/dist/. RPM locator sites A number of sites help you find RPMs for various applications. On the main sites, you can find specially built RPMs for a variety of Linux distributions. You can then download the RPMs made especially for your systems. The main RPM-finding site is rpmfind.net, which offers a search engine as well as software you can run on your site. The RPM PBone Search, at http://rpm.pbone.net/, is also very useful. The www.rpm.org/packagers/ site lists a number of places that package RPMs and provide them for downloading. Many Java libraries and packages are available in RPM format from www.jpackage.org/. Table F-2 lists a number of other RPM download sites. Table F-2 RPM download sites Site Holds rpmfind.net Links to a huge number of RPMs, many specific to various Linux distributions http://rpm.pbone.net/ RPM PBone search, useful for finding RPMs www.rpm.org/packagers/ Lists a number of sites that provide RPMs for download www.javapackage.org Many Java packages in RPM format http://plf.zarb.org/ The Penguin Liberation Front has RPMs that for legal reasons cannot be included in the Mandrake Linux distribution. www.math.unl.edu/~rdieter/Projects Rex Dieter???s RPM site www.rpmhelp.net Mandrake Linux RPMs www.aucs.org/rpmcenter/ Edwin Chan's Red Hat RPMs www.owlriver.com/projects/links/ Owl River Company RPMs RPM tools sites A large number of tools exist to help you work with RPMs. The following sites list some of the main tools: *For the vim text editor, you can download a spec.vim syntax file from http://pegasus.rutgers.edu/~elflord/vim/syntax/spec.vim. *For emacs, you can download an Emacs mode for spec files from http://tihlde.org/~stigb/rpm-spec-mode.el. Cross Reference Appendix F lists links for a number of text editors. *The rpmlint tool mentioned in Chapter 13 is available at http://people.mandrakesoft.com/~flepied/projects/rpmlint/. Table F-3 lists a number of RPM-related tools and the sites you can find more information on the tools. Table F-3 RPM-related tools Tool Site apt-rpm ftp://ftp.conectiva.com/pub/conectiva/EXPERIMENTAL/apt/ apt4rpm http://apt4rpm.sourceforge.net/ AutoRPM www.autorpm.org AutoUpdate www.mat.univie.ac.at/~gerald/ftp/autoupdate current www.biology.duke.edu/computer/unix/current/ kpackage www.kde.org MakeRPM.pl www.perl.com/CPAN/modules/by-authors/id/JWIED poldek http://poldek.pld.org.pl/ rpm2html rpmfind.net/linux/rpm2html/ rpmfind rpmfind.net RUST www.rusthq.com setup.sh www.mmedia.is/~bre/programs/setup.sh urpmi www.linux-mandrake.com/cooker/urpmi.html Programming sites Only a few sites exist to help developers with programming for RPM. I maintain some quick links to RPM sites at www.pconline.com/~erc/rpm.htm. Most of these links are focused for programming with RPM. The best sites for programming RPM are the online API documentation at www.rpm.org/rpmapi-4.1/ for the RPM 4.1 release, and the ftp.rpm.org/pub/rpm/dist/ site for downloading the RPM sources. There is a lot of documentation bundled with the source code. Cross Reference Appendix F lists links for a number of Integrated Development Environments, or IDEs, aimed at programmers. Sites related to RPM If you try to make cross-platform RPMs, especially RPMs that should work for multiple versions of Linux, it is very important to follow the Linux standards for things like file placement and package formats. The Filesystem Hierarchy Standard, or FHS, covers Linux directory layout at www.pathname.com/fhs/. The Linux Standards Base is working on standardizing on the RPM package file format. See www.linuxbase.org for details. Accessing RPM Mailing Lists and Newsgroups The RPM mailing list provides the best source of technical RPM information. You can post questions and get quick, useful responses. If you are working with RPM, you should subscribe to this mailing list. For details on viewing the RPM mailing list archives and signing up for the list, see www.rpm.org/mailing_list/. To help avoid unwanted commercial e-mail (in other words, spam), you need to register with a user name and password to subscribe to the mailing list or view the archives. A Usenet newsgroup, named linux.redhat.rpm, also provides a forum for asking RPM-related questions. You can read this newsgroup with any newsreading program. From fedora-docs-commits at redhat.com Tue Oct 4 01:55:15 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:55:15 -0400 Subject: rpm-guide rpm-guide-other-linuxes-en.xml,NONE,1.1 Message-ID: <200510040155.j941tFuX000762@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv744 Added Files: rpm-guide-other-linuxes-en.xml Log Message: --- NEW FILE rpm-guide-other-linuxes-en.xml --- Using RPM on Non-Red Hat Linuxe Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Chapter *Dealing with RPM issues on other versions of Linux *RPM standardization *Working around RPM differences when installing RPMs *Working around RPM differences when building RPMs *Dealing with non-RPM-based Linux distributions Although its name was originally the Red Hat Package Manager, RPM has been adopted by most major Linux distributions. With this adoption, RPM has moved from its Red Hat roots, and RPM now stands for the RPM Package Manager. In addition, the RPM package format is being adopted by the Linux Standards Base (LSB). The LSB defines a set of standards to help maintain compatibility for all Linux distributions. Cross Reference See www.linuxbase.org for more on the LSB. This chapter covers differences in how Linux distributions use RPM, ways to work around these differences, and also tools you can use for non-RPM distributions. Troubleshooting RPM Installation Issues The main RPM issues when dealing with installing RPMs on other versions of Linux are: *Different versions of RPM itself *Different divisions of software into packages *Dealing with dependency issues *Different install locations The following sections expand on these issues. Dealing with RPM versions Red Hat Linux 8.0 ships with RPM version 4.1. Other distributions of Linux ship with other versions of RPM. Thus, one of the first commands you can run on another Linux distribution is the rpm --version command, to see what RPM version is in use and help identify any issues. For example: $ rpm --version RPM version 4.1 Once you know the RPM version, you can plan for any issues that arise from installing RPMs made with a different RPM version. For example, RPM 4.0 and higher inserts dependency information automatically into RPMs. If your Linux distribution runs RPM 3.x, you may need to disable some of the dependency checks, for example, if you want to install RPMs built under RPM 4.x onto an RPM 3.x system. On installing RPMs, you can disable the dependency checks with the --nodeps option. If you do this, though, you should manually check that the dependencies are really met by your Linux installation. On the other hand, if you want to install RPMs built on an RPM 3.x system onto an RPM 4.x system, you may need to deal with package signatures. RPM 4.x versions also automatically check for signatures. When installing packages on an RPM 4.x system, you can disable this feature with the --nosignature option. Using these techniques, you should be able to install packages built with RPM 4.1 on systems that use RPM 3.x versions or vice versa. Dealing with divisions of software into packages There is no standardization as to how large applications are divided into packages on different Linux distributions. This means that dependencies between packages may differ. If your dependencies are for packages provided with the Linux distribution, which includes a huge number of packages, you must address this issue. The package an RPM depends on may not exist and may not even be needed, on a particular Linux distribution. If instead the dependencies are for files, especially shared libraries, you should be okay for the most part, unless the files are located in different directories. The only real solution to this problem is to turn off dependency checks on installing, with the --nodeps option. Then you must check manually that your system really does provide all the necessary dependencies. Use the techniques shown in Chapter 6 to verify all the dependencies are met on your system. Warning Using the --nodeps option can lead to problems with your RPM database, because you are installing packages by defeating the RPM system's safeguards for dependencies. Only use the --nodeps option if you are really sure the dependencies are met on your system, even if from a different package than expected. Dealing with dependency issues One of the toughest areas to deal with is the problem of dependencies. This topic ranges from the very simple issue of installing a necessary package to complex issues of shared library versions or particular Perl modules. Start with the simple case and make certain that you haven???t failed to install a necessary RPM that provides the right dependency. In most cases, you can download a vendor-specific package from your Linux vendor, such as www.suse.com for SuSE Linux. Most Linux vendors provide HTTP or FTP sites with a large set of packages created for their distributions. If such a distribution-specific package solves a dependency issue, this is the easiest way around the problem. After you verify that you haven't simply omitted a necessary package, move on to other potential explanations. Another issue involves shared libraries and ELF, or Extended Linking Format, symbols. A package may require an older or newer version of a shared library. Applications that are tied to a particular version of a shared library can cause problems, since you may not want to install incompatible versions of a shared library. If the dependency is for a system-shared library, such as the shared C library, you can often recompile the package (rebuild from a source RPM) to get the package to use the newer or older version of the system library. This is possible because most Linux applications don???t call on version-specific features of system shared libraries (some do, but most don???t). If the dependency is for an application-shared library, this is more serious, since there were likely API changes that could impact the application. Install the package owning the application-shared library and again, try to rebuild the package from the source RPM. Cross Reference You can use the rpm -qf command to query which package owns a given file. You can use the rpm -q --whatprovides command to query for which package provides a given capability. Chapter 6 covers more on dependencies. Some packages are considered developer packages. These usually depend on some base package. For example, the rpm-devel package depends on the rpm package. The rpm-python package depends on both the rpm package and the python package (at particular version numbers as well). This naming scheme of a base package and base-devel is used for Red Hat Linux packages, but may not be used for other vendor packages. In any case, you can solve this type of dependency by finding the relevant base packages that the package you are trying to install depends on. Consult the manuals that come with your Linux distribution or browse the online RPM repositories to see what naming conventions are used for your Linux distribution. Many packages depend on scripting language interpreters, such as Perl. Sometimes the dependency is based on scripts used in a package, such as install or trigger scripts. You can have problems arise with the locations of these scripting interpreters. Perl, for example, is usually installed in /usr/bin/perl on most Linux systems. Another common location is /usr/local/bin/perl. In addition, packages may depend on particular add-on modules, especially Perl modules. With most versions of Linux released in the last few years, you should be able to override a Perl dependency with the --nodeps option as long as you have Perl installed. File paths may also cause problems. For example, a file that a package depends on may be in a different location or owned by a different package. For this case, you can try to find the package that owns the file and make sure that package is installed. If your Linux vendor provides a pre-built RPM database of all packages, such as the rpmdb-redhat package, you can query this database to find out which package owns the file for that version of Linux. Dealing with install locations Linux vendors can install software anywhere. For example, some distributions place a lot of software under /opt instead of the more common /usr. From an RPM perspective, this is mostly an issue with file dependencies and the install location for packages. Evolving file system standards also help limit this issue. You can attempt to relocate any package using the --badreloc option. Cross Reference Chapter 4 covers the --badreloc option. But, while the --badreloc option will relocate the files in a package, it will not modify the contents of those files. So, any file inside a package that references files and directory locations may not work properly, since it may have the old, invalid, paths. The only real way around this problem is to edit any script files that come with the package and contain hard-coded paths. If the paths reside inside binary executables, you need to get a source RPM for the package, patch the sources and then create a new RPM. When all else fails, rebuild from the source package When all of these techniques fail to install a package, you still have a fallback option. If you have the source RPM for a package, you can install the source RPM on the new system and then edit the spec file until you can rebuild a package that will install on your version of Linux. For example, a set of Build Root Policy (brp) helper scripts are run at the end of the %install section in an RPM. These scripts perform tasks such as compressing man pages. The Mandrake brp scripts use bzip2 compression. Red Hat brp scripts use gzip compression. This is one case where rebuilding an RPM and then installing may work best. Handling Problems Building RPMs Given all these differences, how can you create RPMs while avoiding problems? With some work setting things up, you can create an RPM build environment that solves most vendor issues. This depends on taking a methodical approach to building your packages and using techniques to avoid vendor issues wherever possible. When building RPMs, you will face many of the same problems@@mdand solutions@@mdas when installing RPMs. For example, due to the different ways Linux vendors divide software into packages, your RPMs will likely have issues defining the proper dependencies. There are also a number of issues that apply only when building RPMs. The following sections cover the main issues when building RPMs. Writing distribution-specific packages One of the ways around all the differences between Linux distributions in RPM usage is to define distribution-specific packages. To do this, you create a separate package on each Linux distribution you support. That???s a lot of work. If possible, fit the differences into macros and use a single spec file to reduce some of this work. This technique works up to a point. Sometimes, your spec file becomes too complicated and you may decide that it is easier to create multiple spec files, one per Linux distribution. One way to help make vendor-specific packages, or to see which RPM macros are defined on a given Linux distribution, is to look for an RPM that contains the distribution-specific RPM configuration. For example, on Red Hat Linux systems, the Red Hat RPM configuration is defined by the redhat-rpm-config package. You can list the files in this package to see where Red Hat defines macros specific to their Linux distribution. $ rpm -ql redhat-rpm-config /usr/lib/rpm/redhat /usr/lib/rpm/redhat/brp-compress /usr/lib/rpm/redhat/brp-redhat /usr/lib/rpm/redhat/brp-sparc64-linux /usr/lib/rpm/redhat/brp-strip /usr/lib/rpm/redhat/brp-strip-comment-note /usr/lib/rpm/redhat/brp-strip-shared /usr/lib/rpm/redhat/find-lang.sh /usr/lib/rpm/redhat/find-provides /usr/lib/rpm/redhat/find-requires /usr/lib/rpm/redhat/macros /usr/lib/rpm/redhat/perl.prov /usr/lib/rpm/redhat/perl.req /usr/lib/rpm/redhat/rpmrc These files, such as /usr/lib/rpm/redhat/macros, show you what is specific to a given Linux distribution. You can then look at the macros defined in these files to identify settings for a particular distribution, in this case, Red Hat. Armed with this knowledge, you can better create portable RPM spec files. Dealing with automatic dependency generation One of the features in RPM 4.x is the automatic generation of dependencies. For a variety of reasons including different package layouts, different directory structures, or different versions of RPM, you may need to disable some or all of automatic generation of dependencies. You can disable the automatic generation of dependencies by placing the following directive in your spec file: Autoreq: 0 If you do so, you need to use the Requires: tag to manually define all requirements. This is not a good solution to the issue of automatic dependencies however. Most likely, you will need to override the %{__find_requires} and %{__find_provides} macros in order to filter out any unwanted dependencies. These two macros resolve to shell scripts that perform the automated dependency checks, as you can see with the rpm --eval command: $ rpm --eval "%__find_provides" /usr/lib/rpm/find-provides rpm --eval "%__find_requires" /usr/lib/rpm/find-requires You can override these scripts to filter out any dependencies that cause problems for your packages. Dealing with different macros Different Linux vendors define different macros in their RPM setup. This may mean not only different values for the macros, but different macro names as well. Because of this, it is best to define your own local set of macros when building RPMs. As much as possible, depend on your own RPM macros. You can define your macros in terms of vendor-specific macros using conditional statements in your spec files, a topic covered in Chapter 11. You can also read examples in the ???Build Environment and Macros??? section of this chapter. This really boils down to creating a disciplined RPM build environment. Making relocatable packages You should aim to make your packages relocatable so that users can install your packages into any directory. This makes it easier to deal with the locations chosen by different Linux distributions, such as /usr, /usr/local, or /opt, for installing add-on software. Cross Reference Chapter 10 covers the spec file format. Chapter 11 covers making relocatable packages. You can use the %{_bindir} macro in your spec files, which will help create per-distribution packages using the right settings. In addition, you can define macros in your spec files that define the location for dependencies. You can then use the --define option to the rpmbuild command to define values for your macros that specify the locations for the dependencies. Note This technique of setting up Linux distribution-specific macros can help solve a lot of problems with cross-platform RPMs. Creating an RPM build environment If you start with the idea that you want to build RPMs for multiple versions of Linux, you can set up an RPM build environment that cleanly separates most vendor-specific issues. The key issues with the build environment are: *Detecting the vendors *Using macros to define a clean build process *Handling different dependencies Detecting Vendors To make a clean build environment, you need to be able to detect the Linux vendor and make build settings based on this vendor. To help with this, many Linux vendors install a special file with the vendor name, or a special package with the vendor name. You can query for either of these. For files, the convention follows: /etc/vendor-release For example: $ more /etc/redhat-release Red Hat Linux release 8.0 (Psyche) For packages, the convention is vendor-release for a package name. For example: $ rpm -q redhat-release redhat-release-8.0-8 You can use either approach or simply define a macro for the vendor and use the --define option to set the macro. For example: # rpmbuild ???ba --define 'linuxVendor suse' With this definition, you can use the macro %linuxVendor inside your spec files. It is generally easier, though, if your scripts can automatically detect the Linux vendor instead of having to define it manually. The manual approach works, though, if it becomes too much effort to detect the vendor automatically. Build environment and macros Once you can detect the Linux vendor, you can create macros based on the differences between Linux distributions that affect your applications. Cross Reference Chapter 21 covers RPM macros. The macros that specifically help you with platform differences include the %if .. %endif conditional. You can use this in combination with special macros you define. In addition, command-line options such as --with, --without, and --target allow you to control features and the build target within an RPM. The %if macro allows you to specify a condition within your spec file. For example: %if %{old_5x} && %{old_6x} %{error: You cannot build for .5x and .6x at the same time} %quit %endif %if %{old_5x} %define b5x 1 %undefine b6x %endif %if %{old_6x} %define b6x 1 %undefine b5x %endif You can also use %if to control settings such as the Requires:, as shown in the following example: %if %{build6x} Requires: util-linux, pam >= 0.66-5 %else Requires: util-linux, pam >= 0.75-37, /etc/pam.d/system-auth %endif The --with command-line option defines a special macro starting with _with_. For example, the following command-line option defines a feature to use: $ rpmbuild ???bc --with ssh filename.spec This example defines the macro _with_ssh to --with-ssh. This format was specially designed to work with GNU configure. You can use this for conditional builds for platform-dependent issues. The --without command-line option similarly defines a macro starting with _without_. The convention is that this option defines a feature the code should not use. You can combine --with and --without to turn on and off features referenced in your spec files. For example: ./configure %{?_with_ssh} This will pass the following command line if the _with_ssh macro is defined: ./configure --with-ssh If this option is not defined, the command will be: ./configure The --target option sets the spec file macros %_target, %_target_arch, and %_target_os . For example: $ rpmbuild -bc --target ppc-ibm-aix /usr/src/redhat/SPECS/jikes.spec Compatibility and Glue Packages Not all Linux distributions are the same. Macros alone won???t provide work-arounds for all the differences. You can, though, get a lot of mileage from compatibility and glue packages. A compatibility package provides a legacy API on newer systems that no longer support the legacy API. By convention, compatibility packages are named with a leading compat- to signify their purpose. For example: $ rpm -q --qf "%{description}" compat-libstdc++ The compat-libstdc++ package contains compatibility Standard C++ Using a compatibility package allows you to create programs that use a least-common-denominator approach, programming to the oldest but most common APIs. As some Linux distributions eliminate the old APIs, compatibility packages can provide the missing APIs. Similarly, a glue package provides a dependency that exists on some Linux distributions but not others. It glues together your package with the Linux distribution that is missing an essential capability. Note A key point in both of these approaches is to separate the compatibility and glue packages from your main application packages. The application packages should be as clean of vendor issues as possible. Instruct your users to install the compatibility or glue packages as needed (based on their Linux distribution) along with the main application package or packages. With all this discussion of RPM and Linux differences, you might think that Linux is one big mess. That???s not true. Linux maintains a high degree of compatibility among Linux distributions as well as among processor architectures. Most programs originally created for Linux on Intel-based architectures compile cleanly on Linux versions running on other processor architectures such as MIPS, SPARC, and ARM. The main differences lie in how Linux vendors split up the huge number of files associated with Linux into RPM packages as well as which versions of tools like C compilers the vendors ship. Dealing with Signatures With SuSE Linux, or any Linux based on UnitedLinux 1.0, the RPM packages are signed with OpenPGP version 4, not 3, as used in RPM 4.1. This means that you must use some other, non-RPM means to extract the signatures from an RPM package, and then verify these signatures with gpg. Dealing with Non-RPM-Based Linux Versions The main Linux distributions that don???t support RPM are the Debian GNU/Linux family and Slackware Linux. To help with these distributions, you can use a package-conversion tool called alien. </sect2> <sect2> <title>Handling non-RPM packages with alien Alien is a package that supports conversions between RPM and so-called alien package formats such as the dpkg (Debian GNU/Linux), slp (Stampede Linux), and tgz (Slackware Linux) formats. You can use alien on your RPM-based Linux system to convert RPMs to some other format, such as the Debian dpkg. You can also use alien to convert other package formats into RPMs, depending on which way you need to go. Standardizing RPMs RPM is being considered as part of the Linux Standard Base, or LSB, 1.3. This will define a standard packaging format for Linux distributions, and over time reduce the RPM differences between distributions. In addition, other efforts are underway to help unify the diverse Linux distributions, including the Filesystem Hierarchy Standard and the adoption of RPM by many Linux vendors. Filesystem Hierarchy Standard The FHS, or Filesystem Hierarchy Standard, defines the purpose of all the upper-level directories on Linux systems, such as /var and /usr/bin. This standard, along with the Linux Standard Base, or LSB, is driving Linux distributions to a greater degree of similarity. The FHS helps by specifying where applications should get installed and which directories should be left to local administrators to manage. The FHS also defines the purpose of all Linux directories, giving vendors and application writers a better idea of where they should install their packages. Cross Reference See www.linuxbase.org for more on the LSB. See www.pathname.com/fhs/ for more on the FHS. RPM adoption RPM has been adopted by a large number of Linux distributions. In addition, standardization efforts, both for RPM and for filesystem locations, are making Linux systems less varied. This means that over time, many of the RPM-related differences between Linux distributions will fade away, making it easier to create cross-platform RPMs. Summary This chapter covers differences in RPM versions between various Linux distributions, and techniques you can use to get around these differences. Each Linux vendor packages software differently, even if the vendor uses RPM. This can cause problems unless you write your spec files carefully. Inside your RPM spec files, you can use conditional elements as well as platform-based macro definitions to help create RPMs for multiple packages. Some of the best conventions are to split the software in your applications from any compatibility or glue packages, separate packages that provide missing features for various flavors of Linux. Standardization efforts such as the Linux Standard Base and Filesystem Hierarchy Standard are bringing Linux vendors closer and closer together. Widespread adoption of RPM by most Linux distributions also helps. While this chapter covers RPM on other Linux distributions, the next chapter tackles RPM outside of Linux. From fedora-docs-commits at redhat.com Tue Oct 4 01:55:48 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:55:48 -0400 Subject: rpm-guide rpm-guide-other-os-en.xml,NONE,1.1 Message-ID: <200510040155.j941tmLx000791@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv773 Added Files: rpm-guide-other-os-en.xml Log Message: --- NEW FILE rpm-guide-other-os-en.xml --- RPM on Other Operating Systems Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Chapter *Running RPM on other operating systems *Bootstrapping RPM on other operating systems *Setting up the RPM environment *Creating non-Linux RPMs *Setting up an RPM build environment *Cross-building packages RPM was originally designed on Linux and for most of its life has been a Linux-centric package management system. But most Linux programs are portable to most versions of Unix or Unix -like operating systems. Linux is, after all, a Unix-workalike operating system. The RPM system is no exception. It has been ported to a number of operating systems, including quite a few Unix variants. The source code is freely available, so you can port RPM to other systems as well. This chapter covers running RPM on non-Linux operating systems, including getting the RPM system in the first place, bootstrapping an RPM environment, and creating packages for other operating systems. The first step is to get RPM for your system, or port RPM if it isn???t already available. Running RPM on Other Operating Systems The RPM system, made up of mostly the rpm and rpmbuild commands, have been ported to a number of operating systems. There is nothing stopping you from running the RPM system on other platforms. Other operating systems have their own native package management software. You may prefer the way RPM works, or merely want to standardize on RPM across all platforms you manage. There will always be a few issues, however, when running RPM on other operating systems. For example, operating system patches and updates are likely to be distributed in the operating system???s native package management format, not RPM. Many applications will be updated also using the system???s native package management format. You will need to always keep in mind that there are two package management schemes in use: RPM and the native one. This issue has not stopped a great many people from using RPM on other systems, though, as shown by the list of platforms RPM has been ported to (see Table 20-1 for the list). On the plus side, package management has always been one of the main areas where versions of Linux, Unix, and other operating systems differ, sometimes quite a lot. By using RPM, you can transfer your knowledge of package management from one system to another, saving valuable time and hassles. You will be able to update systems in the same manner, a big plus if you manage a diverse set of systems. Another reason to use RPM on other operating systems is that in most cases, RPM provides far more capabilities than the native package management software. Following the RPM philosophy, each package can be separately verified, checked, and updated. Each package lists the other packages it depends on, and also lists the capabilities it provides. You can automate the installation and upgrade processes with RPM. You can also perform a lot of version and signature comparisons. All of this leads to a more secure, more robust system. Many operating systems don???t include these capabilities in the native package management software. This is why many users run RPM on other operating systems. Cross Reference See Chapter 2 for more on the philosophy behind RPM. If you decide to use RPM on a non-Linux system, the first step is getting RPM for your system, if it is available. Getting RPM for your system The first step to using RPM on non-Linux platforms is getting the RPM system for your platform. In most cases, this is a relatively easy step, as RPM has been ported to a great many platforms, as listed on the main RPM Web site. Cross Reference Links to RPM versions for various platforms are listed at www.rpm.org/platforms/. Go to this site and download the versions for the platforms you need. Table 20-1 lists the platforms RPM has been ported to, as reported by the RPM site. Table 20-1 Available Platforms for RPM Platform Notes AIX AmigaOS With GeekGadgets BeOS With GeekGadgets FreeBSD HP-UX 10.20+, 9.04 IRIX Linux Multiple platforms including Alpha, Intel, Motorola 68000, SGI MIPS, PowerPC, and SPARC LynxOS MachTen MacOS X Mint NCS System V NetBSD OS/2 OSF/1 3.2+ SCO OpenServer 5.0.2+ Sinix Solaris Solaris for SPARC 2.4 and 8+, Solaris for Intel SunOS 4.1.3 Windows Under Cygwin Note that RPM has likely been ported to even more platforms. These are just the ones reported to the rpm.org site. Note If you fix a bug in RPM on a non-Linux system, or if you port RPM to a new system, please report this to the rpm.org site maintainers, as well as make your work available for others. You never know, but someone else may fix a problem you???re facing. If Table 20-1 does not cover the platforms you need, you must compile and bootstrap the RPM environment for your platforms, as covered in the "Bootstrapping RPM on Other Operating Systems" section, following. Note Don???t expect to find RPMs of the RPM system for these other platforms. If you did, there would be no way to install RPM. Instead, you???ll find RPM packaged in a variety of formats, typically using a native bundling format for a given system, or at least a supported format. Compressed tar files are very common. RPM for IRIX systems come in IRIX tardist format. If RPM is available for your system, download the package and follow any installation instructions that come with the package. For example, RPM for Solaris 8 requires the libiconv library, as well as the Solaris packages SUNWzlib and SUNWbzip. You must install these packages prior to installing RPM. Each operating system will have similar requirements. Windows systems have a few extra requirements due to the fact that Windows is very different from Linux or Unix-like systems. Running RPM on Windows The version of RPM for Windows requires cygwin, originally the Cygnus port of many Unix tools to Windows. Now part of Red Hat, you can download the cygwin environment from the main cygwin site. Cross Reference Download cygwin from www.cygwin.com. You can download a setup.exe program to install the environment on Windows. After installation, you can download the RPM system for Windows. After you have RPM installed, you can set up your RPM system. If RPM wasn???t already ported to your operating systems, however, you will need to bootstrap RPM on your platforms. Bootstrapping RPM On Other Operating Systems If you cannot find a version of RPM that has been ported to your platform, you can port it yourself. The RPM system usually isn???t that hard to port to any platform that can appear like Unix or Linux systems, such as any platform that supports POSIX system calls or something like these system calls. Don???t be dismayed by the sheer size of the RPM package. Much of the RPM system was carefully designed to run across multiple platforms, so file access is abstracted to special portability routines. For example, RPM has been ported to both AmigaOS and BeOS, two non-Unix operating systems. Downloading the RPM software To bootstrap RPM on another operating system, download the RPM source code from the main RPM site. Cross Reference You can download the RPM source code from ftp://ftp.rpm.org/pub/rpm/dist/. Note that you probably do not want to download an RPM of the sources, since your platform won???t have RPM available. In most cases, you???ll want to download a tarred compressed archive, such as rpm-4.1.tar.gz for RPM version 4.1. Extracting the software If the system you plan to port RPM doesn???t have the tar and gzip commands available, or something that supports these formats, then you need to find a way to extract the software. Note Programs such as WinZip on Windows support extracting .tar.gz files. Your platform may have a similar program. One way is to port the gzip and tar commands to your platform. Cross Reference You can download the sources for tar and gzip from www.gnu.org. Another way is to extract the sources on a platform with these commands available, such as a Linux platform. Then, create a file using a format supported by your operating system and transfer the files to the other system. Once you have the RPM source code available on your target system, and all the files are extracted, you are ready to start porting. The first step is really simple: read. Reading the INSTALL file In the main RPM source directory, you will see two very important files: README and INSTALL. Read them both. (You would be surprised at how many times people need to be told this.) Of the two, the INSTALL file has much more detailed information on installing RPM on a new system. The INSTALL file describes the libraries required by RPM, provides tips on compiling RPM, and describes some of the set up work necessary after compiling the RPM system. Some of the hardest parts of the RPM system to port, though, may be in the database, compression, and encryption calls, used as libraries by the RPM system. Libraries required by RPM Rather than invent everything from scratch, the RPM system makes use of a number of libraries, including those listed in Table 20-2. Table 20-2 Libraries used by RPM Library Purpose Berkeley DB RPM database, using db1 and db3 bzip2 Compression gettext International text lookup gpg For digital signatures gzip Compression popt Processing command-line options zlib Compression Read through the INSTALL file to find out where you can download versions of these libraries. You may find that each library has its own set of dependencies, all of which you need to port to your target platform. Tools for building RPM In addition to the libraries listed in Table 20-2, RPM requires a number of GNU utilities for building RPM, including those listed in Table 20-3. Table 20-3 Tools used to build RPM Tool Usage Autoconf Builds configure scripts Automake Used with autoconf GNU make Used to control building the sources Libtool Used by the autogen.sh script In addition to all this, RPM works best with the GNU C compiler, GCC, and the GNU make program, gnumake, or simply gmake. Cross Reference The source code for all the GNU tools is available at www.gnu.org. Compiling RPM After downloading the RPM sources, extracting all the files and installing all the prerequisite libraries, you are ready to start compiling RPM. RPM includes quite a few subsystems, such as popt for parsing command-line options. Each of these subsystems requires some configuration. Most of this configuration is automated through the use of the autogen.sh script and the autoconf/automake tool used to create configure scripts. The autogen.sh script is a Bourne shell script that checks for specific versions of necessary tools and libraries. After checking dependencies, the autogen.sh script calls different autogen.sh scripts in the beecrypt, libelf, popt, and zlib directories. When done with that task, the autogen.sh script calls configure. Pass a command-line option of --noconfigure to disable the call to configure. Edit the autogen.sh script if you are using different versions of the necessary tools. The autogen.sh script is coded to require the specific versions of these tools as were used originally to build the RPM package. In addition, your system may have libraries stored in different locations than those expected by the autogen.sh, so it's a good idea to edit this script and verify all the assumptions. Note One really big assumption in this script is that you have a Unix-like operating system. If not, you will need to determine how to set up the Makefiles manually. This requires a lot of trial and error while you edit the Makefiles and then see if you can build the software. Fix each problem that arises and try again. When you are done with the autogen.sh script, you can use the following basic commands to create system-specific Makefiles, compile RPM and install the commands: $ ./configure $ make $ make install The configure script takes the Makefile.in files and uses these files as templates to create custom versions of Makefile.in files, tuned to your system. (The automake system starts with a Makefile.am file, creates an expanded Makefile.in file, and finally results in a Makefile tuned to your system.) If all else fails, you can copy each Makefile.in file to Makefile and then edit the Makefile to make one that will work on your system. Cross Reference See the GNU site, at www.gnu.org, for more on the autoconf and automake tools. If the make install step fails, you can manually copy the RPM executables and scripts to a directory for system commands. Handling problems If RPM fails to compile or install, you can still work around many issues. The key is to find out what went wrong, fix the problem, and try again. You may go through this loop many times before RPM successfully compiles and installs. Most problems can be solved by changing the configuration settings. If possible, change the inputs to the configure command to specify C compiler options, and so on, that you discover you need. You can then run the basic commands to build RPM again, but with any special options you discovered are necessary: $ ./configure ???any_options_set_here $ make $ make install If you take this approach, you avoid having to edit a number of Makefiles (one in each source code subdirectory) by hand. You also have an easier time of switching to different command-line options as you determine more solutions to the compilation problems. If this won???t work, though, you can edit the Makefile.am file or the generated Makefile directly to add whatever settings are needed. For example, you may need to specify additional directories for libraries, or some C compiler compatibility option. As you discover problems, remember you are not alone in porting RPM. Check the RPM mailing list, where the question of getting RPM going on other platforms comes up frequently. Cross Reference For details on viewing the RPM mailing list archives and signing up for the list, see www.rpm.org/mailing_list/. Setting Up the RPM System Once you have RPM available on your platform, you need to set up the RPM system. This includes setting up the RPM database and creating an RPM environment. Setting up the RPM database After you have the RPM system available on your platform, you need to set up the RPM database. This usually involves two steps: *Initializing an empty RPM database *Populating the database with packages, especially for dependencies Both steps are necessary. Initializing an Empty RPM Database After you have the RPM system installed on your platform, the next big step is to create an RPM database for your platform. You can make an empty database with the rpm --initdb command, as shown following: # mkdir /var/lib/rpm # rpm --initdb The first command creates the default directory for the RPM database. You may need to pass command-line options to specify a non-default location of the RPM database, such as the following: # rpm --dbpath /location/of/your/rpm/database --initdb Use a command like this one if you don???t want to place the RPM database in its default location. In addition, use the ???v option to add more verbose output. This is very useful if errors occur. Use the --root option to specify a different root directory for RPM operations. Use the --rcfile option to specify a non-default set of rc files and the --macros option to specify a non-default set of macros. Cross Reference Chapter 21 covers RPM customization. Initializing the RPM database creates the necessary structure for an empty database. You can then fill, or populate, the database with packages. In most cases, all you need to do is install packages to populate the RPM database, as each installed package gets added to the database. Handling Dependencies for Packages Installed Without RPM Each time you install a package, you populate the RPM database. This works well, as long as you have already installed all the dependencies for the packages you want to install. On an operating system that is based on RPM, such as Red Hat Linux, all packages (except for some bootstrapping code) are installed with RPM. That means nearly everything on the system is defined in the RPM database. The RPM database then has a full knowledge of what you have installed and can properly handle dependencies. Thus, a failure to find a dependency means that you have not installed the requisite package that provides the needed capability. On an operating system that is not based on RPM, however, such as Solaris or IRIX, most packages have already been installed by some means other than RPM.. That???s because these operating systems use different native package-management techniques and different package formats. It is very likely that RPM packages you want to install have dependencies that come from non-RPM packages. For example, the rpm program on Windows depends on the cygwin environment, yet this environment needs to be installed with a Windows setup.exe program, not with the rpm command. To get around this problem, you need to populate the new RPM database with a package or packages that reflect the current system in order to properly handle dependencies. The main way to do this is to set up a virtual package. Setting Up A Virtual Package You can get around the problem of pre-existing software by building a virtual package that lists the system libraries at mdinstalled without RPM at mdin an RPM package. This way, the rpm command will find that the dependencies are installed, even if they were not really installed with RPM. You need to do this for all capabilities and system libraries installed outside of RPM control. To help create such a virtual package, use the vpkg-provides.sh script from the scripts directory. The vpkg-provides.sh script searches a list of directories for shared libraries and interpreters (such as shells). The vpkg-provides.sh script then creates a spec file that lists all the files found, files that are managed outside of RPM. You can use this spec file to create an RPM and install the RPM using the rpm command to populate the RPM database. The RPM spec file created by the vpkg-provides.sh doesn???t really install any files, as all the files are already installed. Instead it makes a package that claims ownership for all these files so that RPM dependencies can function properly. The vpkg-provides.sh script accepts three main command-line options: --spec_header, --ignore_dirs, and --no_verify. The --spec_header option tells the script the name of the RPM spec file it should use as a header for the spec file it will produce. You need to provide the path to the file. For example: # sh vpkg-provides.sh --spec_header /path/to/spec/file You need to provide a spec file header to make a complete spec file. This header should contain the Summary, Name, Version, and Release settings, at least. Chapter 10 covers these spec file tags. The --ignore_dirs option tells the vpkg-provides.sh script to ignore certain directories. You need to pass a list of egrep search patterns that identify the directories to ignore. Separate each pattern with a pipe character, |. Note The egrep command may not be available on your system. It may be easier to edit the vpkg-provides.sh script and manually specify the directories to ignore. The --no_verify option tells the vpkg-provides.sh script to skip the step of creating a script to verify checksums of all files in the package. In addition to these main command-line options, you can also pass the following options to the vpkg-provides.sh script. The --shlib_dirs option tells the vpkg-provides.sh script the directories to look for shared libraries. Pass a colon-delimited list of directories. For example: # sh vpkg-provides.sh --spec_header /path/to/spec/file \ --shlib_dirs "/bin:/usr/bin:/sbin:/usr/sbin:/usr/ucb:/usr/bsd" The --interp_dirs option tells the vpkg-provides.sh script which directories to look in to find interpreters such as sh, bash, perl, wish (Tcl/Tk), and awk. The --interps option tells the vpkg-provides.sh script the names of the interpreter commands. Both these options expect a colon-delimited list. The --find_provides option tells the vpkg-provides.sh script the name of the find-provides script to use, defaulting to /usr/lib/rpm/find-provides. The vpkg-provides.sh script defines specific directories to look in for shared libraries and interpreters under various operating systems. You will most likely need to edit this section. In fact, if you are working with a non-Unix system, or if you experience problems running the vpkg-provides.sh script, you can edit the file to remove the problematic commands. You can also create a new script in a scripting language supported on your system. The vpkg-provides.sh script is a Linux shell script. Linux and Unix systems should be able to run the script, but non-Unix systems likely won???t have the commands and may also not support shell scripts at all. In an effort to be generic, the vpkg-provides.sh script does a lot of work. You can limit this by explicitly specifying directories and commands, for example. And, if all else fails, you can create a virtual package manually (covered in the following section). When complete, the vpkg-provides.sh script outputs a spec file, using the header you provided, and outputs a set of Provides: lines to specify what the package provides. It then outputs some empty definitions for the prep, build, install, and clean sections of the spec file. For example, you can run the vpkg-provides.sh script with a command like the following: $ sh ./vpkg-provides.sh --spec_header my_header.spec --find_provides ./find-provides --no_verify Note If you run this script as a non-root user, you may get a number of permission errors as the vpkg-provides.sh script searches through system directories. The script will then output your spec file header along with output like that shown in Listing 20-1. Listing 20-1: Output from the vpkg-provides.sh script Provides: /bin/sh Provides: /bin/csh Provides: /bin/ksh Provides: /bin/perl Provides: /bin/awk Provides: /bin/nawk Provides: /bin/oawk Provides: /usr/bin/sh Provides: /usr/bin/csh Provides: /usr/bin/ksh Provides: /usr/bin/perl Provides: /usr/bin/awk Provides: /usr/bin/nawk Provides: /usr/bin/oawk Provides: /sbin/sh Provides: /usr/dt/bin/dtksh Provides: /usr/xpg4/bin/sh Provides: /usr/xpg4/bin/awk %prep # nothing to do %build # nothing to do %install # nothing to do %clean # nothing to do %files # no files in a virtual package The vpkg-provides.sh script also outputs a package description that explains how the package was created. This is important so that you know this is a virtual package. When done, use the rpmbuild command to create an RPM from the generated spec file. Cross Reference Chapter 9 covers how to run the rpmbuild command, and Chapter 10 covers spec files in detail. Creating a Virtual Package Manually Even on Unix-like systems you may experience troubles with the vpkg-provides.sh script. That???s simply because the vpkg-provides.sh script assumes a number of Unix and GNU utilities are available. In most cases, it will work best if you can fix what went wrong and run the vpkg-provides.sh script again. If all else fails, though, you can create a virtual package spec file manually. Create a spec file starting with the Summary, Name, Version, and Release settings. Looking at the output shown in Listing 20-1, you can create a Provides: statement for each shared library on your system, and each interpreter, such as shells. Add each statement to your spec file. For example: Provides: libgen.so Copy the prep, build, install, and clean sections exactly as they are in Listing 20-1. You can now run the rpmbuild command to create a virtual package. Install this package. Creating the RPM environment The RPM environment is made up of a large number of RPM settings and macro definitions. Run the rpm --showrc command to see the current environment settings on Linux: $ rpm ???showrc ARCHITECTURE AND OS: build arch : i386 compatible build archs: i686 i586 i486 i386 noarch build os : Linux compatible build os's : Linux install arch : i686 install os : Linux compatible archs : i686 i586 i486 i386 noarch compatible os's : Linux RPMRC VALUES: macrofiles : /usr/lib/rpm/macros:/usr/lib/rpm/i686-linux/macros:/etc/ rpm/macros.specspo:/etc/rpm/macros.db1:/etc/rpm/macros.cdb:/etc/rpm/macros:/etc/ rpm/i686-linux/macros:~/.rpmmacros optflags : -O2 -march=i686 This output was truncated for space. As you can see, there are a lot of expected settings. You need to set up these same settings and macros, but with the proper values for the new system on which you are running RPM. The files rpmrc.in and macros.in serve as the default templates used to create the rc and macro settings, respectively. These files are modified by the configure script to include values specific to the local operating system. You can edit these files as needed for your system, prior to installing RPM. That is, edit these files between calling the make command and the make install command. Cross Reference Chapter 21 covers how to customize the RPM settings and macros, along with the popt aliases. The INSTALL file in the RPM sources also describes some modifications you may want to make to the macros. Creating Non-Linux RPMS Once you have RPM set up on a system, you should be able to create RPMs using the rpmbuild command on that system. Warning Do not build RPM packages logged in as a root or Administrator user. If something goes wrong, rpmbuild could destroy files in your system. Remember that spec files can define a number of commands and shell scripts. Any of these could have an error that could cause major damage when run as a root user. Before building RPMs with the rpmbuild command, though, you may want to customize the build environment to better reflect your system. You may also find it is too difficult to build most RPMs on the non-Linux system and instead focus on cross-building packages, should the rpmbuild command not work on the target systems. This section covers topics related to building RPMs on or for non-Linux systems. Setting up a build environment In RPM terms, your build environment consists of the directories where you build RPMs, as well as the rc and macro settings that define all of the variables in an RPM-based system. To set up your build environment, you need to ensure that all the rc and macro settings reflect the true environment on your non-Linux system. The rpm --showrc command, discussed previously in the "Creating the RPM Environment" section, lists the settings for your system. You can use this command to verify all the settings. You may want to change some settings, such as the top directory where RPMs are built. By default, this setting is something like the following: _topdir %{_usrsrc}/redhat Cross Reference See Chapter 21 for more on how to customize the rc and macro settings. In most cases the _topdir setting on Red Hat Linux systems map to the /usr/src/redhat directory. Your system may not even have a /usr/src directory. Also you may not want to build RPMs in a redhat directory, which may cause confusion if you are building on a non-Red Hat Linux system. Cross Reference See Chapter 19 for more information on setting up a build environment for RPMs. Chapter 19 focuses on other Linux systems, but many of the same techniques apply. With a build environment set up, you should be able to create RPMs with the rpmbuild command. If this doesn???t work, or is too difficult, then you can try cross-building packages. Cross-building packages You may find that it is too difficult to create RPMs on a given platform. It may be easier to build the RPMs on another platform, such as a Linux system, as if it were on the target platform. This is called cross-building packages, since you are building a package on one system specifically designed for another. In most cases, the target platform is quite different from the system where you cross-build packages. Otherwise, you would likely just build the RPMs on the target platform. The key issues with cross-building are the following: *You must compile any executables with a cross compiler for the proper target platform. *You must set the target platform in the RPMs you build. *You must manage dependencies, and likely need to turn off the automatic generation of dependencies. Note Setting up a cross-building environment is oftentimes more work than it is worth. If you can compile applications and build packages on the target system, do that. The cross-building option should be used only if you really cannot build packages on the target system. For example, many handheld or small-format computers lack the processor performance or memory to compile applications. These are good candidates for cross-building. To compile executables for another platform, especially a platform with a different processor architecture, you need a cross compiler. A cross compiler runs on one system and produces executables for another. Note Cross compilers are heavily used when working with embedded and small device systems. The embedded system may not have the processor power to compile applications, or it may simply be inconvenient to compile applications on the embedded system. The Linux gcc compiler can act as a cross compiler if you install the right gcc add-on packages. See the GNU site for more on the gcc compiler. Cross Reference You can download GCC and other GNU software from www.gnu.org. In addition to compiling for the target platform, you need to ensure that the RPM is marked as being for the target architecture. If not, the rpm command will fail when trying to install the RPM on the target system. You can set the target architecture with the --target option to the rpmbuild command. For example: rpmbuild ???bi --target arm-sharp-linux This specifies a target CPU architecture of ARM, the vendor Sharp (which just happens to make an ARM-based Linux device) and the operating system of Linux. The basic format is: cpu-vendor-os Cross Reference See Chapter 12 for more on using the --target option to the rpmbuild command. You must also turn off or correct any automatically generated dependencies in RPMs you build for other platforms. That is, any dependencies based on the operating system or architecture of the system you are cross-building on will likely not be found, or be found in a different location or format, on the target platform. This is where the handy RPM feature of automatically building the dependencies does not work to your advantage. You can turn off this feature, however. Cross Reference See Chapter 19 for information on how to turn off the automatic generation of dependencies. You should turn off the automatically building of dependencies for any packages you cross build. Using these techniques, you can build packages on one system for use on another, very different system. Due to the difficulties, you should only go this route if it becomes too difficult to use the rpmbuild command on the target systems. Summary With its superior package-management capabilities, especially for automated installations and upgrades, you may want to use RPM on non-Linux platforms. As the experience of many developers has shown, you can indeed use RPM on non-Linux platforms. The rpm.org site maintains a listing of operating systems where developers have ported RPM. If you are lucky, you can download RPM for your operating system and start working right away. If you are not lucky, you will need to port RPM to your target system. If RPM has been ported to your architecture, download the package and follow the installation instructions. If RPM has not been ported to your architecture, download the RPM sources and all prerequisite libraries. You may need to port each library to your architecture before you can even begin to port RPM. The RPM sources use a configured build process that also requires some prerequisite tools. You need to get or port these to your architecture as well. Whew. Once everything is in place, you can start the port of RPM. In many cases, you just need to figure out how to get RPM to compile and everything will fall into place. In other cases, you will need to work on each RPM subsystem to get it to build and run. After you have RPM for your system, you need to initialize the RPM database with the rpm --initdb command. You can then start to populate your RPM database. Because a large number of libraries have already been installed on your system, you may need to create a virtual package that claims to provide these files. Installing such a virtual package will allow you to install other RPMs that may be dependent on system libraries. Much of porting RPM to another platform depends on the RPM environment and how you need to customize that environment. The next chapter shows how to customize your RPM environment, on Linux or on other operating systems. From fedora-docs-commits at redhat.com Tue Oct 4 01:56:33 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:56:33 -0400 Subject: rpm-guide rpm-guide-package-structure-en.xml,NONE,1.1 Message-ID: <200510040156.j941uXLx000820@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv802 Added Files: rpm-guide-package-structure-en.xml Log Message: --- NEW FILE rpm-guide-package-structure-en.xml --- RPM Package File Structure Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Appendix *RPM package file structure *RPM header entry formats *Payload format This appendix describes the format of RPM package files. You can combine this information with C, Perl, or Python data structures to access the information. In all cases, you should access elements in an RPM file using one of the available programming libraries. Do not attempt to access the files directly, as you may inadvertently damage the RPM file. Cross Reference Chapters 16, 17, and 18 cover programming with C, Python, and Perl, respectively. The RPM package format described here has been standardized as part of the Linux Standards Base, or LSB, version 1.3. Cross Reference The LSB 1.3 section on package file formats is available at www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB.html#PACKAGEFMT. The Package File RPM packages are delivered with one file per package. All RPM files have the following basic format of four sections: *A lead or file identifier *A signature *Header information *Archive of the payload, the files to install All values are encoded in network byte order, for portability to multiple processor architectures. The file identifier Also called the lead or the rpmlead, the identifier marks that this file is an RPM file. It contains a magic number that the file command uses to detect RPM files. It also contains version and architecture information. The start of the identifier is the so-called magic number. The file command reads the first few bytes of a file and compares the values found with the contents of /usr/share/magic (/etc/magic on many UNIX systems), a database of magic numbers. This allows the file command to quickly identify files. The identifier includes the RPM version number, that is, the version of the RPM file format used for the package. The identifier also has a flag that tells the type of the RPM file, whether the file contains a binary or source package. An architecture flag allows RPM software to double-check that you are not trying to install a package for a non-compatible architecture. The signature The signature appears after the lead or identifier section. The RPM signature helps verify the integrity of the package, and optionally the authenticity. The signature works by performing a mathematical function on the header and archive section of the file. The mathematical function can be an encryption process, such as PGP (Pretty Good Privacy), or a message digest in MD5 format. The header The identifier section no longer contains enough information to describe modern RPMs. Furthermore, the identifier section is nowhere near as flexible as today???s packages require. To counter these deficiencies, the header section was introduced to include more information about the package. The header structure contains three parts: *Header record *One or more header index record structures *Data for the index record structures The header record identifies this as the RPM header. It also contains a count of the number of index records and the size of the index record data. Each index record uses a structure that contains a tag number for the data it contains. This includes tag IDs for the copyright message, name of the package, version number, and so on. A type number identifies the type of the item. An offset indicates where in the data section the data for this header item begins. A count indicates how many items of the given type are in this header entry. You can multiply the count by the size of the type to get the number of bytes used for the header entry. Table D-1 lists the type identifiers. Table D-1 Header type identifiers Constant Value Size in Bytes RPM_NULL_TYPE 0 No size [...2175 lines suppressed...] 1.3 The package conforms to the Linux Standards Base RPM format. rpmlib(VersionedDependencies) 3.0.3-1 The package holds dependencies or prerequisites that have versions associated with them. rpmlib(PayloadFilesHavePrefix) 4.0-1 File names in the archive have a ???.??? prepended on the names. rpmlib(CompressedFileNames) 3.0.4-1 The package uses the RPMTAG_DIRINDEXES, RPMTAG_DIRNAME and RPMTAG_BASENAMES tags for specifying file names. /bin/sh NA Indicates a requirement for the Bourne shell to run the installation scripts. The payload The payload, or archive, section contains the actual files used in the package. These are the files that the rpm command installs when you install the package. To save space, data in the archive section is compressed in GNU gzip format. Once uncompressed, the data is in cpio format, which is how the rpm2cpio command can do its work. In cpio format, the payload is made up of records, one per file. Table D-10 lists the record structure. Table D-10 cpio file record structure Element Holds cpio header Information on the file, such as the file mode (permissions) File name NULL-terminated string Padding 0 to 3 bytes, as needed, to align the next element on a 4-byte boundary File data The contents of the file Padding 0 to 3 bytes, as needed, to align the next file record on a 4-byte boundary The information in the cpio header duplicates that of the RPM file-information header elements. From fedora-docs-commits at redhat.com Tue Oct 4 01:57:09 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:57:09 -0400 Subject: rpm-guide rpm-guide-packaging-guidelines-en.xml,NONE,1.1 Message-ID: <200510040157.j941v9WQ000849@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv831 Added Files: rpm-guide-packaging-guidelines-en.xml Log Message: --- NEW FILE rpm-guide-packaging-guidelines-en.xml --- Packaging Guidelines Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Chapter *Avoiding common mistakes *Following good practices RPM is a complex system that helps manage thousands of packages for a complex operating system. Furthermore, RPM is very, very flexible. This flexibility makes it important that you follow the rules to create packages the proper way. Otherwise, you???ll face a host of problems with your RPMs. Following some best practices guidelines will help you avoid future problems as you release RPM updates. This chapter covers ways to avoid common problems as well as best-practice guidelines for creating your own RPMs. Avoiding Common Problems Developers creating RPMs seem to hit many of the same roadblocks. This section covers some of the most common problems faced by RPM users and package builders. Warning Never, never, never build RPMs logged in as the root user. See the section on Building for details. Scan the mailing lists Many people have tried to solve a lot of serious problems that arise when using RPM, so if you are facing difficulties, chances are someone else has tackled those issues before. The RPM mailing list provides a technical forum for discussing RPM issues and problems. In many, if not most, cases, you can find answers to problems by scanning the mailing list archives. You can also sign up for the mailing list so that you can send in requests and see the responses. Cross Reference For details on viewing the RPM mailing list archives and signing up for the list, see www.rpm.org/mailing_list/. See http://groups.yahoo.com/group/rpm-list/messages for an archive of the list. If you are working with RPMs and pushing the envelope for other operating systems or complicated packages, this list is definitely worth a look. Before sending any messages, though, be sure to look through the message archives to see if the message has already been answered. You will save time waiting for a response if you can get an archived response right away. You should also ask any questions in a way that will generate the most helpful responses. This includes: Do your homework first. Check to see if your question has already been answered by looking at the mailing list or newsgroup archives. In the end, this saves you the most time, as you don???t have to wait for answers. Describe the problem and the symptoms as clearly as possible. After all, this is what you want help with. Use clear subject headers. This is the first part of your message that people will read. If you are not clear, the key people who could answer your questions may never even read your message. And, if they don???t read the message, you will never get an answer. Send your message in plain text, not HTML. Do not include a separate HTML copy of your message. This just makes it harder to read, especially for people who read collected digests of mailing lists. Make it easy for people to reply to you. Include your email address in your message. You might want to include a line that states something like ???Please send your reply to me at??? and then provide your email address. Cross Reference These tips on asking questions come from the Internet document on How to Ask Questions the Smart Way by Eric Steven Raymond and Rick Moen, available at multiple sites, including www.owlriver.com/tips/smart. In addition to the RPM mailing list, there is also a Usenet newsgroup, named linux.redhat.rpm. You can read this newsgroup with any newsreading program. Note Newsgroups are sometimes called discussion groups. Use rpmbuild In older versions of RPM, you called the rpm ???ba command to build RPMs. With RPM 4.1, you must use the rpmbuild command. If you have the rpmbuild command available, even if you are running an older version of RPM, run rpmbuild instead of rpm to build your RPMs. You???d be surprised at how such a simple item is one of the most-asked questions on the RPM mailing list. That???s because the rpm ???ba command, and the other ???b options, no longer work in RPM 4.1. These options are supported by the rpmbuild command. Don???t try to defeat the system If you are finding your spec files getting more and more complex, and that you are trying to disable RPM features, chances are you are trying to defeat the system. This is not a good idea. The RPM system works in a certain way. You may not always agree with the way it works, but if you try to make it work in contrary ways, in most cases you???ll end up fighting RPM to no avail. There are certain rules, and more importantly certain conventions that RPMs should follow. The previous chapters in this section on building RPMs have outlined those conventions. Follow them. When you go against these conventions, you are really trying to defeat how the RPM system works. Turn off automatic dependency generation When you build an RPM, the rpmbuild command will automatically generate dependencies on Linux shared libraries and other system commands. You can turn this off if you need to, using a number of means. You can disable the automatic generation of dependencies by placing the following directive in your spec file: Autoreq: 0 A better approach, though, is to override the %{__find_requires} and %{__find_provides} macros, or just one of these as needed. You can null out either of these macros by adding commands like the following to your spec file: %define __find_requires %{nil} This approach is better because it allows you to override only the requires checks. In addition, you can get more specific and simply change how the automatic dependency checks are performed. For example, you can also change the definitions of these macros to perform normal dependency generation except for any problematic files or packages. These two macros resolve to shell scripts that perform the automated dependency checks, as you can see with the rpm --eval command: $ rpm --eval "%__find_provides" /usr/lib/rpm/find-provides rpm --eval "%__find_requires" /usr/lib/rpm/find-requires You can override these scripts to filter out any dependencies that cause problems for your packages. Don't list directories in %files Unless you really mean it, don???t list directories in your %files section in your spec files. That is because the rpmbuild program will automatically add all files in that directory to your RPM. If this is a system directory, such as /usr/bin, your RPM has now claimed ownership for all the files, regardless of the source package. To avoid all files in the directory becoming part of the package, list the files explicitly, perhaps generating the list of files as the program builds. If you do need a directory installed as part of your package, use the %dir directive, described in Chapter 10. Handling circular dependencies If two packages each depend on the other, you don???t want each package???s spec file to list the other in a Requires section. If this occurs, the packages won???t install without one of the force options, since each package will require the other to be installed first. Cross Reference Chapter 4 covers how to install or upgrade packages while ignoring dependency checks. In general, you do not want to ignore these checks. You can work around this issue by using the PreReq directive instead of Requires. For example, if package A depends on B and package B depends on A, you can place the following in the package B spec file: PreReq: A In addition, you can install both packages at the same time to avoid some of the problems with circular dependencies. Simply include both packages on the rpm ???Uvh command line. Following Good Practices Working through problems is one thing. It???s best, however, to set up an environment to help avoid problems all together. The following sections cover what are considered the best practices for creating RPMs. Before you make an RPM, you should plan out what you intend to build and how it will be structured. As you build the RPM, you want to watch out for things that can go wrong, and work from a known clean environment. Preparation Before you start to make an RPM, you need to follow a few steps to ensure you have everything ready. Create a Source RPM Having a source RPM allows you to transfer all the sources for a package from one system to another, along with all the instructions coded in the spec file for actually building the binary package. This is very handy for keeping track of software, and it is also very important since you can regenerate the binary RPM at any time from the source RPM. In other words, make the generation of RPMs follow the RPM conventions and fit this into your normal software build process. This means that for each RPM you want to build, you really need two: a source and a binary RPM. This isn???t that hard to do, since you can easily make a source RPM into a binary RPM with the rpmbuild command. Start with Pristine Sources In addition to planning on making a source RPM, you should also start with pristine, unmodified sources for the application you plan to package as an RPM. Starting with pristine sources means you can reproduce the entire process and recreate the RPM from scratch if necessary. (Quality control and configuration management people really appreciate this.) The pristine sources should be exactly the sources you got when you downloaded the application, or acquired it in house. This doesn???t mean that you won???t have to modify the sources eventually. For that, you create patches. The key is just to start the process with unmodified sources. Some RPMs have nearly 100 patches that the rpmbuild command applies when building the RPM. That is a lot of patches, too many for most applications. Even so, the process is the same. Create a patch or patches for all the changes you need to make. You can easily specify patches in the spec file. Cross Reference Chapter 10 covers the spec file. Keeping your patches separate from the original sources makes it easier to reproduce the RPM from scratch, and makes it easier to integrate a new version of the base software, since your code, in the form of patches, is separated from the base software code. Decide What Goes In Each Package You don???t have to stuff all your software into one RPM. Instead, you can often simplify your RPM by dividing it into two or three separate (but likely dependent) RPMs. For example, the RPM system itself has one RPM for the basic system, rpm, one for developers of the RPM system, rpm-devel, and one for those building RPMs, rpm-build. Yet another RPM provides the Python programming API, rpm-python. Cross Reference Chapter 17 covers Python programming. This last division is important. The Python RPM draws in as a dependency the Python system itself. Adding this into, say, the core RPM package would needlessly complicate the dependencies for that package. When dividing your software into RPMs, keep two main issues in mind: *You want to divide the software into RPMs that fit the model for users of the system. *You want to divide the software into RPMs such that the separate RPMs are simpler to create and manage. The RPM system follows these guidelines, especially the first. Few users will extend the RPM system itself, which allows RPM team to shed this functionality from the core RPM and contain it in rpm-devel. Those who build RPMs fit into a different category than those who use RPMs since just about everybody needs to use RPMs to install packages, but few users actually build RPMs. Again, the separation works from a user???s perspective. You also want your package divisions to make each package easier to specify. You can break particularly tough dependencies into smaller units and simplify things. If the package division doesn???t simplify things, then it may not be a good idea. Create a Test RPM Database You don???t always have to work with the system RPM database. In fact, while developing RPMs, you probably don???t want to change the system database. If you have a test RPM database, you can install your RPMs into this test database. To do so, use the --justdb, --dbpath, --prefix, and --badreloc options. These options allow you to install an RPM into just the database, using a different database, with a different root file location (into a test directory, for example) and handle all files that were not marked for relocation, respectively. Note The --test option when installing also allows you to just test the install, not actually perform it. Combined, all these options mean you can use an RPM database just set up for testing and that problems won???t impact your working Linux systems. To make this work, though, you need a test RPM database. To be rigorous, you should create the test RPM database from scratch from a known set of packages. This will allow you to exactly verify the behavior of your RPM under different system configurations. This is the best choice since you should install the packages under a known, and non-root, directory hierarchy to avoid having file problems with the working system. If you want to cheat, you can copy your real RPM database to another directory and use that. Note that in this case, the file paths in the database will point to the real file locations on disk. Regardless of how you create a test database, recreate the database each time you run a test, so that you are sure of a known starting state. Usually this is as simple as copying a master test RPM database into a directory you use for running tests. Building Building RPMs isn???t as easy as it should be. You???ll often need to try again and again to get the rpmbuild command to create a working RPM. This section covers best practices to follow when performing the actual build of the RPM. Use Tools Using tools can help speed up the RPM-making process, as well as give you a head start in learning how RPMs work. RPM-building tools such as the Red Hat plugin for the Eclipse Integrated Development Environment have proven really helpful. Cross Reference Chapter 13 covers RPM-building tools. Appendix F covers the Eclipse Integrated Development Environment. Even though so-called real Linux hackers can make a working virtual memory system with just the cat command, don???t scoff at tools. Your time is too valuable. Another useful tool is the gendiff program that comes with the RPM release. The gendiff program makes it easier to create patches by avoiding the need to keep a separate directory of the original sources, The gendiff program also works on all changed files within a directory, making a patch for everything you modified. To work with gendiff, you need to first save a backup copy of each file you intend to edit prior to editing. Use a consistent file-name extension for the saved copies of the files, such as .orig, short for original. After you edit some files, run the gendiff command as follows: $ gendiff directory_name .saved_extension > patch_name.patch For example, if you saved the original files to a .orig extension, you can create a patch in a directory named src (short for sources) with a command like the following: $gendiff src .orig > mypatch.patch The patch file mypatch.patch will contain all the differences detected for all files in the given directory. Never Build RPMs as Root Never, never, never build RPMs logged in as the root user. Always build your RPMS while logged in as a normal user. This is hard to remember since you must be logged in as root to install an RPM. And you???ll want to test each RPM you create to see if it can install cleanly. Even so, never build RPMs logged in as the root user. The RPM spec file has a number of scripts and commands. An error in any of these could cause damage to your system. This includes modifying files, removing files, or copying new contents on top of system files. The root user has permission to perform all these operations. To avoid all this, build your RPMs while logged in as a normal user. Any problematic scripts should generate errors. Create a Digital Signature RPM 4.1 and later revisions place more importance on signing your packages. The rpm command will, by default, verify signatures on each package it reads. Therefore, you should create a digital signature for your packages, if only to meet user expectations. In addition, you should place a copy of your digital signature on your organization???s Web site and public key servers. Having multiple copies in multiple locations helps prevent malicious users from impersonating your keys. Cross Reference Chapter 12 covers signing packages. Copy Smartly Your Linux distribution probably includes more than one CD-ROM chock full of RPMs. Each of these RPMs has a spec file. You can examine these spec files and see how others choose to build their RPMs. Rather than starting from scratch, you can copy declarations from these spec files into your spec file. Not all these packages were made smartly. Some spec files, as you will see, are a large mess. Obviously, don???t copy these. Look for clean spec files with clear directives. Set Up the BuildRoot A BuildRoot directive sets the location where your code will be built. The convention is for you to define a subdirectory beneath the _tmppath directory. For example: BuildRoot: %{_tmppath}/%{name}-buildroot Once set, rpmbuild defines the RPM_BUILD_ROOT environment variable to the value specified for the BuildRoot. With the rpmbuild command, you can use the --buildroot option to specify a directory to use to override the BuildRoot directive in the spec file. Using a BuildRoot set to a directory that normal users have write access to allows you to build the package logged in as a normal user. It also helps separate the contents of your package from those of other RPMs. Always define a BuildRoot. Add changelog entries for each new version Each time you create a new version in RPM format, you should add an entry to the change log. This allows administrators to get a better idea about what changed from the previous version. The change log can help people decide whether or not to upgrade a package. A log entry about a security fix, for example, provides useful information to users. Define the Group For Your Package Packages are categorized into groups. These group names, while not always the best, appear in the graphical tools such as the Red Hat package manager. If your application is a Linux shell program, then users will expect to find it in the System Environment/Shells group and not the Development/Languages or System Environment/Daemons groups. This is a rather small detail, but it helps users find your package in the huge array of Linux RPMs. The official list of RPM groups is located in /usr/share/doc/rpm-4.1/GROUPS for RPM 4.1, and similarly-named directories for other RPM versions. Summary This chapter covers guidelines for avoiding problems when creating RPMs and following best practices to avoid future problems as well. When trying to avoid common problems, your best starting point is the RPM mailing list and newsgroup. For best practices, you should start at the very beginning when you are planning what to build into an RPM. Always start with pristine sources and then patch as needed. Your RPM should include the pristine sources and any necessary patches. You should always create a source RPM, so that you can reproduce your RPM anywhere. When building RPMs, copy good examples of spec files, as this will get you going far more quickly than any other technique. Use tools to help automate parts of your RPM-building process. Never build RPMs when logged in as the root user. This chapter ends the section on building RPMs. The next section covers programming to the RPM APIs. From fedora-docs-commits at redhat.com Tue Oct 4 01:57:53 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:57:53 -0400 Subject: rpm-guide rpm-guide-programming-c-en.xml,NONE,1.1 Message-ID: <200510040157.j941vrHk000878@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv860 Added Files: rpm-guide-programming-c-en.xml Log Message: --- NEW FILE rpm-guide-programming-c-en.xml --- Programming RPM with C Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Chapter *Using the RPM C library *Setting up a development environment *Programming with the RPM C library *The power of popt for command-line argument processing *Comparing package files to installed packages The RPM C library allows you to perform all the operations of the rpm command from within your own C or C++ programs. The reason is simple: The rpm command was created using the RPM libraries. These same libraries are available for you to use in your own programs. The rpm command itself is quick and, for the most part, simple. So, why would you want to write RPM programs? There are many reasons, some of which are listed here: *Speed: If you need to perform a task on many RPM files such as verifying a large set of files, then performing the task from one program will be a lot faster than launching the rpm command for each file. *Custom options: If you need to do something the rpm command doesn't offer, or doesn't make easy, then you may want to write your own program. *Convenience: If you need to make many packages quickly, with custom options, your best bet may be to create a program suited for your tasks. Before doing this, though, be sure to look into whether writing a shell script will handle your task adequately. You'll find writing RPM shell scripts goes much faster than writing whole programs. *Installation programs: The Windows world has standardized on graphical installation programs such as InstallShield or InstallAnywhere. The RPM system, on the other hand, has focused on automated installation with the rpm command. You can combine the best of both worlds by writing a graphical installation program on top of the RPM system. *Integration with environments: You may want to better integrate RPM with a Linux desktop environment such as GNOME or KDE. *Working with other languages: This book covers programming RPM with C, the core language for the library, as well as the Python and Perl scripting languages. You can use the RPM library, though, to help bind with other languages such as Tcl, Ruby, or even C# (especially one of the C# implementations for Linux). This chapter and the next cover RPM programming. This chapter covers the RPM C programming library, which provides low-level access to RPM functionality. The next chapter covers the RPM Python programming library, which provides a much higher-level of abstraction. If you are attempting to write a complex RPM program, your best bet is to try the Python API first. Even so, there is a lot you can do with the RPM C library. Programming with the C Library RPM C programs are C programs that call on functions in the RPM library, often called rpmlib. To use the rpmlib, you need to set up a C programming environment and install the rpm-devel package. Setting Up a C Programming Environment At the very least, you???ll need a C compiler, gcc, and a text editor. The easiest way to get the C compiler is to install the packages grouped under Software Development with the Red Hat package management tool. Cross Reference See Chapter 8 for more on the Red Hat package management tool. The gcc package requires a number of capabilities. Make sure you install all the necessary packages. Just about every Linux distribution includes gcc and everything you need to develop C programs, so this should not be a problem. For text editors, you can use the vi or emacs text editors, or any of a number of graphical editors such as gedit. Cross Reference Appendix F covers Linux text editors and development tools. Once you have a C programming environment set up, you next need to get the RPM library for an RPM development environment. Setting Up the RPM Programming Environment To program with the RPM library, you need to install the rpm-devel package. You must have a version of rpm-devel that matches your version of the rpm package. If you have Red Hat Linux, your installation CDs will also have the version of the RPM development package that corresponds to your system. Your program should link against the same libraries that are used by the rpm command itself in order to insure compatibility, so make sure that the version of the rpm-devel package matches the rpm package itself. In most cases, the best bet is to use the RPM programs and libraries that come with your version of Linux. Cross Reference You can also download the rpm packages from ftp://ftp.rpm.org/pub/rpm/dist/. This site includes versions of the RPM libraries going back to 1996, ancient history in terms of Linux. The package you need is rpm-devel. If you installed Red Hat Linux 8.0, the package is rpm-devel-4.1-1.06. This package includes header files, documentation, and libraries. Using the RPM Library All C programs using the RPM library need to include the file rpmlib.h, which defines the core data structures, constants, and functions. One thing you???ll quickly note is that the RPM C library accesses RPM data at a very low level. This is one reason why many developers are moving to Python for their RPM programs, since the Python RPM API presents a higher level of abstraction. Cross Reference [...3592 lines suppressed...] ts = rpmtsCreate(); /* Check for query mode. */ if (qva->qva_mode == 'q') { /* Make sure there's something to do. */ if (qva->qva_source != RPMQV_ALL && !poptPeekArg(context)) { fprintf(stderr, "no arguments given for --query"); exit(EXIT_FAILURE); } ec = rpmcliQuery(ts, qva, (const char **) poptGetArgs(context)); } /* Check for verify mode. */ else if (qva->qva_mode == 'V') { rpmVerifyFlags verifyFlags = VERIFY_ALL; /* Verify flags are negated from query flags. */ verifyFlags &= ~qva->qva_flags; qva->qva_flags = (rpmQueryFlags) verifyFlags; /* Make sure there's something to do. */ if (qva->qva_source != RPMQV_ALL && !poptPeekArg(context)) { fprintf(stderr, "no arguments given for --verify"); exit(EXIT_FAILURE); } ec = rpmcliVerify(ts, qva, (const char **) poptGetArgs(context)); } else { poptPrintUsage(context, stderr, 0); exit(EXIT_FAILURE); } ts = rpmtsFree(ts); context = rpmcliFini(context); return ec; } There is not a lot of code in rpmq.c, as this program is mostly calling the high-level functions for the rpm command-line interface. When you run the rpmq program, it performs the same tasks as the rpm command with the --query (or -q) and --verify (or -V) command-line options. For example, rpmq supports query formats: $ ./rpmq -q --qf "%{NAME} %{INSTALLTID:date}\n" jikes jikes Fri 25 Oct 2002 06:49:38 PM CDT Where to Go from Here There is a lot more you can do with the RPM library; you're limited only by your imagination. The best way to get started is to follow the examples in this chapter and then try out some RPM programs on your own. After working with the RPM library for a while, you can delve into other RPM topics. The RPM Web site, at www.rpm.org, has most of the available documentation on the RPM system. This site also includes official RPM released software. One of the best ways to help find out about how to perform RPM tasks is to look at the source code for the rpm program itself. For this, download the rpm-src source RPM, too. To see the rpm command-line interface functions in action, look especially at tools/rpmcache.c and tools/rpmgraph.c, two relatively short RPM files that show how to take advantage of a number of short cuts. The source code for the Python and Perl bindings can also provide extra hints about the purposes of the RPM API calls. The RPM Web site also has a cross-referenced set of HTML pages on the RPM programming API. The pages for version 4.1 of RPM are available at www.rpm.org/rpmapi-4.1/. A good starting page is www.rpm.org/rpmapi-4.1/modules.html, which lists a number of modules within the overall RPM library. This extra level of organization can help you locate the functions you need. Summary Everything you can do with RPM you can program in C. That???s because the source code for the entire RPM system is available. In addition, the rpm and rpmbuild programs make use of a published API, called rpmlib, to access RPM functionality. You can use this library yourself. The popt library, short for parse options, provides a lot of handy utilities for parsing very complex command-line options. You can use popt inside your own programs, even if you don???t use the rest of the RPM functionality. Most RPM programs start up by calling rpmcliInit, which sets up RPM variables for the large set of command-line options supported by most RPM commands. Call rpmReadPackageFile to read in the Header object from a package file. You can also get Header objects for the packages installed in a system by initializing an iterator to iterate over a set of packages that meet a certain criteria. This chapter covers a fairly low level of access to RPM functionality. The next chapter, on Python programming, shows a higher level of abstraction for working with RPM. From fedora-docs-commits at redhat.com Tue Oct 4 01:58:20 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:58:20 -0400 Subject: rpm-guide rpm-guide-programming-perl-en.xml,NONE,1.1 Message-ID: <200510040158.j941wKjI000907@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv889 Added Files: rpm-guide-programming-perl-en.xml Log Message: --- NEW FILE rpm-guide-programming-perl-en.xml --- Programming RPM with Perl Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Chapter *Using the RPM2 module to access information on package files *Querying the RPM database from Perl *Cross-referencing capabilities by the packages that provide and require capabilities *Extracting information on packages Perl is one of the most popular scripting languages. Used by system administrators, software developers, and a host of other users, Perl runs on many operating systems including Linux, UNIX, and Windows. Perl stands for Practical Extraction and Report Language, or sometimes Pathologically Eclectic Rubbish Lister. Note In the same vein, LISP stands for Lots of Irritating Single Parenthesis and COBOL for Completely Obnoxious Business Oriented Language. I began my book Cross-Platform Perl (John Wiley & Sons, 2000) by mentioning that when I first started learning Perl, I thought it was an evil plot. I still do. But it is a very practical evil plot. You can get a lot of work done with Perl, and quickly. Because of a long history of text processing, Perl is especially popular among system administrators. Perl also supports add-on packages, called modules. You can find thousands of add-on modules for text processing, networking, and a plethora of other tasks. There are so many modules available that some people who don???t like the Perl syntax script with Perl anyway, because the available modules save a lot of time. Cross Reference See search.cpan.org, the Comprehensive Perl Archive Network, for a listing of many Perl modules. This chapter covers working with RPM files and the RPM database using Perl. You can combine RPM usage with other Perl usage, such as generating HTML files or downloading RPMs over a network link. Cross Reference Many of the RPM tools covered in Chapter 8 are written in Perl. Getting and Using the Perl RPM Modules A number of Perl RPM modules are available. No one module provides all the features you need, although with time, the Perl modules will consolidate into a few modules that most everyone uses. As of this writing, the RPM2 module, by Chip Turner of Red Hat, provides the most recent approach to working with the RPM system from Perl. This chapter covers the RPM2 module. Red Hat Linux 8.0 comes with a perl-RPM2 package, which you need to install to use this module. Otherwise, you can download the module from www.cpan.org. Install this module, as well as the perl module, which provides the Perl language interpreter. Once you have this module installed and the perl package installed, you are ready to go. Note The version of the perl-RPM2 package that ships with Red Hat Linux 8.0 has a bug in that it will not open package files that were created with the version of rpm that ships with Red Hat Linux 8.0. That is, the Perl module cannot read package files that ship with Red Hat Linux. You can read older package files, though. This problem only affects attempts to read .rpm files, not installed packages. The bug is related to reading signed packages but not having the GPG keys in the keyring. The latest version on search.cpan.org fixes this problem. The RPM2 module contains Perl methods to work on two types of RPM objects: RPM files and installed packages. Working with RPM Files The RPM2 module provides a top-level object, RPM2, that acts as an entry point into the module. From the RPM2 object, you either open the RPM database, covered in the "Programming with the RPM Database" section, or open an RPM package file, covered here. The first step in working with an RPM file is to open the file inside a Perl script. Opening package files The open_package subroutine opens an RPM package file and returns a header object (an RPM2::Header). The basic syntax follows: my $header = RPM2->open_package( $filename ); For example: my $header = RPM2->open_package("jikes-1.14-1-glibc-2.2.i386.rpm"); After you???ve opened a package, you can perform a number of query operations on the header object returned by the open_package subroutine. Listing tags from the package Each RPM package has information stored under a variety of tags, such as the package name under the NAME tag and the package long description under the DESCRIPTION tag. Cross Reference These are the same tags introduced with the --queryformat option to the rpm command discussed in Chapter 5. The tag subroutine returns the value of a given tag. For example, to get the name of the package, use the NAME tag: use RPM2; my $header = RPM2->open_package("jikes-1.14-1-glibc-2.2.i386.rpm" ); print $header->tag("NAME"), "\n"; Pulling this together, Listing 18-1 shows example script that lists the name and one-line short summary of a package file. Listing 18-1: rpmsum.pl #!/usr/bin/perl # # Lists summary from an RPM package file # Usage: # rpmsum.pl package_name.rpm # use strict; use RPM2; my $header = RPM2->open_package( $ARGV[0] ); print $header->tag("NAME"), ": ", $header->tag("SUMMARY"), "\n"; Enter this script and name the file rpmsum.pl. When you run this script, you need to pass the name of a package file on the command line. For example: $ ./rpmsum.pl jikes-1.14-1-glibc-2.2.i386.rpm jikes: java source to bytecode compiler Convenience methods The RPM2 module includes convenience methods for all RPM tags. This means you can use the method name in place of tag("NAME"). For example: print $header->name(), ": ", $header->summary(), "\n"; Listing the name and version The RPM2 module provides a handy subroutine for getting the NAME, VERSION, RELEASE, and EPOCH tags, often abbreviated as NVRE. The subroutine, as_nvre, returns a single string with these values in the standard format, with the values separated by minus signs. Note Usually, the EPOCH tag has no value. If there is an EPOCH value, you will see it output first, and then a colon, and then the name, version, and release values. For example: 5:redhat-config-httpd-1.0.1-13 In this case, the EPOCH value is 5. You can call this subroutine on any header object, or any package object to get the full name of the package. For example: print $header->as_nvre(), "\n"; Checking whether the package is a source package Another handy subroutine tells you if an RPM file represents a source RPM or a binary RPM. The is_source_package subroutine returns a true value if the package is a source package, and a false value otherwise. The rpmpkg.pl script, shown in Listing 18-2, shows how to use the as_nvre and is_source_package subroutines. Listing 18-2: rpmpkg.pl #!/usr/bin/perl # # Queries RPM package file and prints # out name and whether this is a source pkg. # Usage: # rpmpkg.pl package_name # use strict; use RPM2; my $header = RPM2->open_package( $ARGV[0] ); if ( $header->is_source_package() ) { print "Source package ", $header->as_nvre(), "\n"; } else { print $header->as_nvre(), "\n"; } Programming with the RPM Database In addition to providing query routines for RPM files, you can also access the RPM database with the RPM2 package. To access the RPM database, your Perl script must first open the database. Opening the database Open the RPM database with a call to open_rpm_db on the RPM2 object. For example: my $rpm_db = RPM2->open_rpm_db(); You can also specify the directory where the RPM database resides. This is most useful for accessing a database in a non-standard location. For example: my $rpm_db = RPM2->open_rpm_db( "-path" => "/var/lib/rpm" ); Note The -path is normally used as a Perl bareword but is shown here as a string. Once you have an RPM database object, you can call one of the find subroutines to find packages in most of the same ways as supported by the rpm ???q command. Finding packagesc The find_by_name subroutine finds a package or packages by name. It returns a Perl list of the entries found. For example, if you installed more than one version of a package, find_by_name would return a list of all the packages at the different versions. Similar to find_by_name, find_by_name_iter returns an iterator to iterate over the packages that match the query. The iterator approach is usually more efficient. Iterating over packages Iterators are important in the RPM2 package because they provide a more efficient interface to potentially large sets of packages, and because iterators more closely match the underlying C API. Furthermore, iterators are very easy to use. Simply call the next subroutine to move ahead to the next element, that is, the next package. For example: my $pkg_iter = $rpm_db->find_by_name_iter( "kernel" ); while (my $pkg = $pkg_iter->next() ) { # Do something ... } Listing 18-3 shows a script that acts much like the rpm ???q command, without any other command-line options. Listing 18-3: rpmname.pl #!/usr/bin/perl # # Queries RPM database for given package. # Usage: # rpmname.pl package_name # use strict; use RPM2; my $rpm_db = RPM2->open_rpm_db( "???????path" => "/var/lib/rpm" ); my $pkg_iter = $rpm_db->find_by_name_iter( $ARGV[0] ); while (my $pkg = $pkg_iter->next() ) { print $pkg->tag("NAME"), "-", $pkg->tag("VERSION"), "\n"; } $rpm_db->close_rpm_db(); When you run this script, you need to pass the name of a package to query. For example: $ ./rpmname.pl kernel kernel-2.4.18 Additional query subroutines The find_by_name_iter subroutine finds a package by its name. The RPM2 module also supports a number of other query routines, listed in Table 18-1. Table 18-1 RPM2 module query routines Routine Usage find_all() Returns a list with all the packages in the database find_all_iter() Returns an iterator over all the packages in the database find_by_file($filename) Finds all packages that own the given file, returning a list find_by_file_iter($filename) Finds all packages that own the given file, returning an iterator find_by_name($package_name) Finds all packages with the given name, returning a list find_by_name_iter($package_name) Finds all packages with the given name, returning an iterator find_by_provides($capability) Finds all packages that provide the given capability, returning a list find_by_provides_iter($capability) Finds all packages that provide the given capability, returning an iterator find_by_requires($capability) Finds all packages that require the given capability, returning a list find_by_requires_iter($capability) Finds all packages that require the given capability, returning an iterator To verify the find routines, you can try the following script and compare the results with the rpm command. Listing 18-4 shows the script that finds what package provides a capability and also which packages require the capability. Listing 18-4: rpmprovides.pl #!/usr/bin/perl # # Queries RPM database for given package, # listing what it provides and what other # packages require the capability. # # Usage: # rpmprovides.pl package_name # use strict; use RPM2; my $rpm_db = RPM2->open_rpm_db(); my $pkg_iter = $rpm_db->find_by_provides_iter( $ARGV[0] ); print "Provides: ", $ARGV[0], "\n"; while (my $pkg = $pkg_iter->next() ) { print "\t", $pkg->as_nvre(), "\n"; } # Now, what packages require this capability. my $pkg_iter2 = $rpm_db->find_by_requires_iter( $ARGV[0] ); print "Requires: ", $ARGV[0], "\n"; while (my $pkg2 = $pkg_iter2->next() ) { print "\t", $pkg2->as_nvre(), "\n"; } $rpm_db->close_rpm_db(); When you run this script with the name of a capability, you'll see output like the following: $ ./rpmprovides.pl httpd Provides: httpd httpd-2.0.40-8 Requires: httpd mod_perl-1.99_05-3 5:redhat-config-httpd-1.0.1-13 mod_python-3.0.0-10 1:mod_ssl-2.0.40-8 Note The 5: in 5:redhat-config-httpd-1.0.1-13 and 1: in 1:mod_ssl-2.0.40-8 represent the EPOCH tag value. To verify this script, run the rpm -q command to see if you get the same packages listed. For example: $ rpm -q --whatprovides httpd httpd-2.0.40-8 $ rpm -q --whatrequires httpd mod_perl-1.99_05-3 redhat-config-httpd-1.0.1-13 mod_python-3.0.0-10 mod_ssl-2.0.40-8 In both cases, you see the same packages listed. You can use this technique to verify your scripts. Note The find_by_provides_iter subroutine requires the name of a package, such as bash. You cannot pass a file name, such as /bin/bash, to get the name of the package that provides this capability (a file, really). Getting information on packagesng information on packages The tag, as_nvre, and is_source_package subroutines that worked on header objects read from RPM files, shown previously, also work with package entries returned from the RPM database. For example, Listing 18-5 shows a script, rpminfo.pl, that prints out descriptive information about a given package. Listing 18-5: rpminfo.pl #!/usr/bin/perl # # Queries RPM database for given package and prints info. # Usage: # rpminfo.pl package_name # use strict; use RPM2; my $rpm_db = RPM2->open_rpm_db( "-path" => "/var/lib/rpm" ); my $pkg_iter = $rpm_db->find_by_name_iter( $ARGV[0] ); while (my $pkg = $pkg_iter->next() ) { printInfo( $pkg ); } $rpm_db->close_rpm_db(); # Prints info on one package. sub printInfo { my($pkg) = shift; print $pkg->as_nvre(), ", ", $pkg->tag("ARCH"), ", ", $pkg->tag("OS"), ", ", $pkg->tag("PLATFORM"), "\n"; print $pkg->tag("SUMMARY"), "\n"; print "Group: ", $pkg->tag("GROUP"), "\n"; print $pkg->tag("DESCRIPTION"), "\n"; print "Vendor: ", $pkg->tag("VENDOR"), ", ", $pkg->tag("URL"), "\n"; print "Size: ", $pkg->tag("SIZE"), "\n"; } When you run this script, you???ll see output like the following: $ ./rpminfo.pl XFree86 XFree86-4.2.0-72, i386, linux, i386-redhat-linux-gnu The basic fonts, programs and docs for an X workstation. Group: User Interface/X XFree86 is an open source implementation of the X Window System. It provides the basic low level functionality which full fledged graphical user interfaces (GUIs) such as GNOME and KDE are designed upon. Vendor: Red Hat, Inc., http://www.xfree86.org Size: 30552239 Listing the Installed Date The installed date is a number value representing the number of seconds since the start of the UNIX epoch, January 1, 1970, which predates the start of the Linux epoch by about 20 years. So, when you get the value of the INSTALLTIME tag, you???ll see a meaningless number. To make sense of this number, pass the value to the Perl localtime function. Listing 18-6 shows an example of this. Listing 18-6: rpmdate.pl #!/usr/bin/perl # # Queries RPM database for given package, # prints out name, vendor, and date installed. # Usage: # rpmdate.pl package_name # use strict; use RPM2; my $rpm_db = RPM2->open_rpm_db(); my $pkg_iter = $rpm_db->find_by_name_iter( $ARGV[0] ); while (my $pkg = $pkg_iter->next() ) { printDate( $pkg ); } $rpm_db->close_rpm_db(); # Prints installation data for one package. sub printDate { my($pkg) = shift; my $date = localtime( $pkg->tag("INSTALLTIME") ); printf("%-20s %-17s %s\n", $pkg->as_nvre(), $pkg->tag("VENDOR"), $date); } Note The printf function in this script can do something the rpm command cannot do. Even with the --queryformat option, you cannot group multiple items and then set the size; with Perl, you can. Simply assign the multiple values to a string, or use the handy as_nvre subroutine, which gathers up to four tags together into one string. When you pass the name of a package to this script, you???ll see the date the package was installed. For example: $ ./rpmdate.pl kernel kernel-2.4.18-14 Red Hat, Inc. Sat Oct 5 12:29:58 2002 Handling String Array Tags Not only is the date stored in a format that adds complication to your script. A number of tags are string arrays, not scalar strings. This means you may see output that is all mashed together. To help deal with this, the following subroutine takes in an array of strings and returns a string that is built using a passed-in delimiter: sub arrayToString { my($sep) = shift; my(@array) = @_; my($str); $str = $array[0]; for ( $i = 1; $i < $#array; $i++ ) { $str = $str . $sep . $array[$i]; } return $str; } Note Show your Perl expertise and earn extra points by implementing the arrayToString subroutine as a single Perl statement that uses the join function. The following list shows the tags that are an array of strings: *BASENAMES *CHANGELOGNAME *CHANGELOGTEXT *DIRNAMES *FILEGROUPNAME *FILELANGS *FILELINKTOS *FILEMD5S *FILEUSERNAME *OLDFILENAMES *PROVIDENAME *PROVIDEVERSION *REQUIRENAME *REQUIREVERSION Cross Reference Chapter 5 covers more on these tags. Listing the Files In A Package The files subroutine provides a list of all the files in a package. Listing 18-7 shows how to access this list. Listing 18-7: rpmfiles.pl #!/usr/bin/perl # # Queries RPM database for given package, # prints out the files in the package. # Usage: # rpmfiles.pl package_name # use strict; use RPM2; my $rpm_db = RPM2->open_rpm_db(); my $pkg_iter = $rpm_db->find_by_name_iter( $ARGV[0] ); while (my $pkg = $pkg_iter->next() ) { printFiles( $pkg ); } $rpm_db->close_rpm_db(); # Prints installation data for one package. sub printFiles { my($pkg) = shift; my $files = arrayToString("\n", $pkg->files() ); print "Files:\n", $files, "\n"; } sub arrayToString { my($sep) = shift; my(@array) = @_; my($str); $str = $array[0]; for ( my $i = 1; $i < $#array; $i++ ) { $str = $str . $sep . $array[$i]; } return $str; } When you run this script, you???ll see output like the following: $ ./rpmfiles.pl jikes Files: /usr/bin/jikes /usr/doc/jikes-1.17/license.htm Comparing versions The RPM2 module overrides the spaceship operator, <=>, to perform version comparisons between packages. The script in Listing 18-8 shows how to compare all local RPM files against the newest installed version of the same package, if the package is installed. Listing 18-8: rpmver.pl #!/usr/bin/perl -w # # Compare versions of all *.rpm files against the # latest packages installed (if installed) # # Usage: # rpmver.pl # This script looks for all *.rpm files. # use strict; use RPM2; my $rpm_db = RPM2->open_rpm_db(); for my $filename (<*.rpm>) { my $h = RPM2->open_package( $filename ); # Ensure we compare against the newest # package of the given name. my ($installed) = sort { $b <=> $a } $rpm_db->find_by_name($h->name); if (not $installed) { printf "Package %s not installed.\n", $h->as_nvre; } else { my ($result) = ($h <=> $installed); if ($result < 0) { printf "Installed package %s newer than file %s\n", $installed->as_nvre, $h->as_nvre; } else { printf "File %s newer than installed package %s\n", $h->as_nvre, $installed->as_nvre; } } } The sort { $a <=> $b } in front of the find_by_name call sorts all the packages of that name by the version number, so that the comparison is performed against the newest installed version of the package. The ($h <=> $installed) compares the header from the RPM file on disk against the newest installed version of the package. When you run this script, you???ll see output like the following, depending on which RPM files you have in the local directory: $ perl rpmver.pl Package acroread-4.0-0 not installed. Package canvas-7.0b2.0-1 not installed. Installed package jikes-1.18-1 newer than file jikes-1.14-1 Installed package SDL-1.2.4-5 newer than file SDL-0.9.9-4 Package ted-2.8-1 not installed. Closing the database When you are done with the RPM database, call close_rpm_db, as shown following: $rpm_db->close_rpm_db(); Note that this call is not necessary, as the RPM2 module will close the database when the object, in this case $rpm_db, goes out of scope. Where to Go from Here One of the strengths of Perl is that there are so many add-on packages available. In addition, Perl is really strong in text processing. You can combine these strengths to provide cleaner output for RPM database queries, for example, avoiding the complex syntax for the --queryformat option to the rpm command. Perl can do more than the --queryformat option allows. For example, you can combine multiple values together into a Perl string and then format the output. The --queryformat option only allows formatting on each value individually, not groups of values. In addition, you can combine one of the Perl templating modules, such as Text::Template or HTML::Template, to create an HTML page for a given package. You could use Perl to create formatted HTML pages for all the installed packages on your system, with HTML links to cross-reference all the dependencies. Cross Reference Download these modules from the CPAN site, www.cpan.org. This chapter covers the RPM2 module. Right now, the RPM2 module supports only querying packages and the RPM database. Future versions will likely add the ability to install, update, and remove packages. In addition to this module, you can find an RPM module with RPM::Header and RPM::Database classes. Another module, RPM::Specfile, provides the ability to turn Perl modules, such as those stored on CPAN, into RPM packages. The RPM::Specfile module helps create an RPM spec file for a Perl module. The Perl-RPM-Perlonly bundle provides an alternative version of the RPM::Header module written entirely in Perl with no usage of the C rpm library. This makes RPM access much easier on platforms for which you don???t have the RPM system. The RPM-Tools bundle includes RPM::Update, which compares the packages installed on your system (listed by calling rpm ???qa) with the packages available on another system, that may be available only with a network link. This module can also update packages that are older than the designated master system. RPM::Make, also part of the RPM-Tools bundle, helps create RPM packages from a Perl script. This module does not support all the spec file options described in Chapter 10, but it can help you make simple packages. You can download all these modules from the CPAN site. Summary This chapter introduces the RPM2 add-on module to allow Perl scripts to access information on RPM package files and in the RPM database. To access an RPM file and query information about that file, you need to call the open_package subroutine. Once you???ve opened the file, you can call the tag, as_nvre, is_source_package, and files subroutines on the header object to query data about the package. To access the RPM database, call open_rpm_db. Once you???ve opened the database, you can call one of the find subroutines, such as find_by_name or find_by_name_iter, to search for packages. The subroutines that have names ending with _iter, such as find_by_name_iter, return an iterator object to iterate over the packages found. The other find subroutines, such as find_by_name, return a Perl list of the packages found. You can then call the tag, as_nvre, and files subroutines on the package objects to query information about the packages. When you are done with the RPM database, call close_rpm_db. From fedora-docs-commits at redhat.com Tue Oct 4 01:58:55 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:58:55 -0400 Subject: rpm-guide rpm-guide-programming-python-en.xml,NONE,1.1 Message-ID: <200510040158.j941wtKA000944@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv918 Added Files: rpm-guide-programming-python-en.xml Log Message: --- NEW FILE rpm-guide-programming-python-en.xml --- Programming RPM with Python Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Chapter *Using the RPM with Python *Installing the necessary modules *Programming with the RPM database *Programming with RPM files *Installing packages programmatically P Setting Up a Python Development Environment Setting up a Python development environment is much the same as setting up a C programming environment. You need to install a set of packages for general Python development, install a package that provides the Python API to the RPM system, and choose a program for editing your Python scripts. Cross Reference Appendix H covers Linux text editors and development tools. If you want to make a graphical user interface in your Python programs, you need to install a separate Python package. Installing the base Python packages The base Python package needed for developing applications is python. For RPM usage, you should install Python 2.2, not Python 1.5. That???s because the RPM bindings for Python are moving to support only 2.2 and higher releases. The Python package for RPM access is rpm-python. Install these as you would any other packages. Cross Reference Chapter 4 covers installing packages. Using Python for graphics Python supports a number of different toolkits for creating graphical user interfaces. You need one of these toolkits if you want to create Python applications that sport a user interface instead of command-line tools. Among the most popular toolkits are PyGKT, PyQt, and Tkinter. *PyGTK is a binding between Python and the GTK+ toolkit used by the GNOME desktop, one of two main desktop environments for Linux. (KDE is the other main desktop environment.) The Red Hat redhat-config-packages program uses PyGTK and sports a very good-looking user interface. PyGTK provides full access to the GTK+ widgets such as menus, dialog windows, and buttons. Install the pygtk2 module for PyGTK. For more on PyGTK, see www.daa.com.au/~james/pygtk/. *PyQt connects Python scripts to the Qt C++ user interface toolkit. Qt forms the base library used by the KDE desktop environment and KDE applications. As with PyGTK, PyQt allows you to access the rich widget set provided by the library. Install the PyQt package for PyQt. For more on PyQt, see www.riverbankcomputing.co.uk/pyqt/. *Tkinter is considered a standard part of Python and is based on the Tk (pronounced teekay) toolkit from the Tcl scripting language. The main advantages of Tkinter are that it is considered part of Python, meaning users are more likely to have it, and Tkinter works on multiple platforms, including Windows. The main drawback of Tkinter is that the widget sets are not as rich as PyQt or PyGTK. For more on Tkinter, see www.python.org/topics/tkinter/. After you???ve set up your environment and installed all the necessary packages, the next step is to start working with the Python API for RPM. The Python API Hierarchy The RPM Python API provides a high-level abstraction into RPM functionality divided into logical areas. Table 17-1 lists the main RPM types. In most cases, you need to begin with rpm and create a transaction set. Table 17-1 Python types for RPM usage Class Covers rpm RPM base module into RPM API rpmts Transaction sets rpmte Transaction elements, a package in a transaction set rpmmi [...2692 lines suppressed...] # rpm -q jikes jikes-1.17-1 # python rpmupgrade.py jikes-1.18-1.i386.rpm Upgrading jikes-1.18-1 This upgrade will install: jikes-1.18-1 jikes-1.17-1 Running transaction (final step)... Opening file. 4 0 0 jikes-1.18-1.i386.rpm 1 Closing file. 2 0 2854204 jikes-1.18-1.i386.rpm 1 # rpm -q jikes jikes-1.18-1 This example shows that the package was upgraded after running the rpmupgrade.py script. Note that with an upgrade, the original package, jikes-1.17-1 in this case, is also added to the transaction set. With an install, this is not the case. That???s because the original package is removed as part of the transaction. If you run this script as a non-root user, you will likely see an error like the following: $ python rpmupgrade.py jikes-1.18-1.i386.rpm Upgrading jikes-1.18-1 This upgrade will install: jikes-1.18-1 jikes-1.17-1 Running transaction (final step)... error: cannot get exclusive lock on /var/lib/rpm/Packages error: cannot open Packages index using db3 - Operation not permitted (1) error: cannot open Packages database in /var/lib/rpm If a package has a dependency on a file such as a shared library, you will see output like the following: # python rpmupgrade.py jikes-1.17-glibc2.2-1.i386.rpm jpilot-0_97-1_i386.rpm Upgrading jikes-1.17-1 Upgrading jpilot-0.97-1 Must find file [ libpisock.so.3 ] Error: Unresolved dependencies, transaction failed. (('jpilot', '0.97', '1'), ('libpisock.so.3', None), 0, None, 0) If a package has a dependency on another package, you will see output like the following: # python rpmupgrade.py eruby-devel-0.9.8-2.i386.rpm Upgrading eruby-devel-0.9.8-2 Must find package [ eruby-libs - 0.9.8 ] Error: Unresolved dependencies, transaction failed. (('eruby-devel', '0.9.8', '2'), ('eruby-libs', '0.9.8'), 8, None, 0) Where to Go from Here The RPM bindings for Python are documented along with the C programming API. On a Red Hat Linux system, look in the file /usr/share/doc/rpm-devel-4.1/apidocs/html/group__python.html to see the start of the Python-specific documentation. Note that much of this online documentation covers the C functions that provide the Python bindings, not the Python API itself. But, if you examine the online information on objects listed as classes, such as rpmts, you can find the Python-specific documentation. Furthermore, if you look into the .c files that make up the Python bindings, you can find PyMethodDef structure tables. These tables provide useful glimpses into the Python API. To learn more about programming in Python, install the python-docs package. The python-docs package has a large set of online documentation for Python, including the official Python Tutorial. With Red Hat Linux, start at /usr/share/doc/python-docs-2.2.1/html/tut/tut.html. Cross Reference Other tutorials are available at http://diveintopython.org for the Dive Into Python tutorial for experienced programmers, and at http://py.vaults.ca/parnassus/apyllo.py/935043691.636055170 for the Vaults of Parnassus listing of tutorials. Summary This chapter introduces the high-level RPM API for Python programming. You can use this API from Python scripts to perform RPM functionality, just as you can write C programs using the RPM C API covered in Chapter 16. In general, the Python API is simpler and requires fewer code statements than the corresponding functionality in the C API. Just about all of your work with the Python API requires a transaction set, which you can get by calling rpm.TransactionSet. To query the RPM database, call dbMatch on the transaction set object. To install or upgrade packages, call addInstall, check, order, and run on the transaction set. The next chapter switches to another language for accessing the RPM system: Perl. With the rich set of APIs, you can write your RPM programs in C, Python, Perl, or any language that can call on code written in one of these languages. From fedora-docs-commits at redhat.com Tue Oct 4 01:59:32 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 21:59:32 -0400 Subject: rpm-guide rpm-guide-rpmbuild-en.xml,NONE,1.1 Message-ID: <200510040159.j941xWBD000973@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv955 Added Files: rpm-guide-rpmbuild-en.xml Log Message: --- NEW FILE rpm-guide-rpmbuild-en.xml --- Controlling the Build with rpmbuild Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Chapter *Building with the rpmbuild command *Building RPMs without an external spec file *Working with source RPMs *Optimizing builds *Signing built RPMs The preceding chapters in this Part cover details on how to put together RPMs. This chapter rounds out the discussion by delving into more details on the rpmbuild command. You can customize how rpmbuild creates RPMs, and you can use RPM commands to test and debug your package. Building RPMs with the rpmbuild Command The rpmbuild command provides a workhorse command for building RPMs in all sorts of ways. The basic syntax, as shown in Chapter 9, is: rpmbuild -bBuildStage spec_file The BuildStage is a letter, such as c, to prepare and compile the application, executing through the %build section, or i, to execute through the %install section. This allows you a good deal of flexibility for building the entire RPM or stopping at some point prior to a full build. There???s more to the rpmbuild command, though. Quite a few additional options allow you to further customize the build. Note As mentioned in Chapter 9, previous versions of the RPM system used the rpm command with a -b, for build, option. This option is no longer supported. Use the rpmbuild command to build RPMs. Customizing the build You can customize the rpmbuild command with the options listed in Table 12-1. Table 12-1 Extra build options for the rpmbuild command Option Usage --buildroot directory Override the default root directory for building with directory, generally not very useful since most packages already name a buildroot --clean Remove the build tree after building --nobuild Just test the spec file and do not run the build --rmsource Remove the sources after the build --rmspec Remove the spec file after the build --short-circuit With the -bc or -bi options, jump directly to the given stage and resume the build from that stage --sign Sign the package with a GPG signature --target platform Build for the given platform. May not work if you don't have the other platform build commands, such as cross compilers, set up. Can work for Intel platforms with i386, i686, and so on. Testing the build One of the most useful options is --nobuild, which tells the rpmbuild command to not build anything. This may seem silly, but the --nobuild option is very useful for testing whether your RPMs can be built. With the --nobuild option, the rpmbuild command parses the spec file and checks for errors, but does not run any of the build stages. The --buildroot allows you to specify a different top-level directory for building, overriding the BuildRoot tag in the spec file. This means you can build in a separate location, which is helpful in case there are mistakes. Using a separate directory means the build won???t get mixed with anything else in the build root directory. Debugging the build The --short-circuit option tells the rpmbuild command to restart at a particular location in the build. Rather than working its way through all the steps up to the build stage you ask for, the --short-circuit option allows the rpmbuild command to restart just at the step you ask for. Note This works with the -bc and -bi options only, as well as the -tc and -ti options covered later in this chapter. For example, if you run the rpmbuild -bc command to stop after the %build section, you can use the --short-circuit option to restart the build at the %build section. If you found a problem in the %build section and corrected it, you can quickly get going again by restarting the build at the %build section rather than extracting all the sources yet again. This option is most useful when you are compiling a package, hit an error, and fix that error. Without the --short-circuit option, you???ll likely end up spending a lot of time recompiling the code you have already compiled. During normal development of an RPM package, you will likely execute each build section, one at a time, stop, fix any errors and restart where you left off. You???ll go through this cycle a number of times before the RPM finally builds right. Warning Never distribute an RPM made with the --short-circuit option. Instead, once you have everything working, start from scratch and rebuild the RPM. This is to avoid any problems with a partially-created RPM. Cleaning up The --clean option tells the rpmbuild command to remove the build tree when complete. This helps ensure that the next time you run the rpmbuild command, you are starting from a known situation. For example: $ rpmbuild --clean /usr/src/redhat/SPECS/jikes.spec Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.98247 + umask 022 + cd /usr/src/redhat/BUILD + rm -rf jikes-1.17 + exit 0 You can use the --clean option alone, as shown previously, or in concert with another option such as -bi to build and install a binary RPM. In the latter case, the rpmbuild command will clean the built files after the rest of the command finishes. Similarly, the --rmsource option tells the rpmbuild command to remove the sources after completing the command. You can call this option with another option, such as -bi for building and installing a binary RPM (and then removing the sources), or alone on the command line to remove the sources only. For example: rpmbuild --rmsource jikes.spec Note The abbreviation rm is short for remove. It comes from the Linux rm command, used for removing files. The --rmspec option tells the rpmbuild command to remove the spec file when done with the command. As with the --rmsource option, you can use the --rmspec option in conjunction with another rpmbuild option or on its own to just remove the spec file. For example: rpmbuild --rmspec jikes.spec Warning The file you are removing with this command is the spec file you are passing to the command. Be careful, because you cannot undo this operation and you have now lost your spec file, except inside your source package. Building for other platforms The --target option tells the rpmbuild command to build a package for another platform. You need to pass the name of the platform. For example: rpmbuild -bi --target i486-redhat-linux The basic format is: cpu-vendor-os For example, i686-redhat-linux specifies a 686 CPU with Red Hat Linux. Other CPUs include ppc for PowerPC and sparc for Sun SPARC. Cross Reference The --target option sets the target architecture at build time. Chapter 4 covers how you can use the --ignoreos and --ignorearch options when installing RPMs to ignore the operating system and architecture that is flagged within the RPM. Of course, this works only if you are installing on a compatible architecture. On the surface level, the --target option overrides some of the macros in the spec file, %_target, %_target_arch, and %_target_os. This flags the RPM for the new target platform. Under the covers, setting the architecture macros is not enough. You really cannot create a PowerPC executable, for example, on an Intel-architecture machine, unless you have a PowerPC cross compiler, a compiler that can make PowerPC executables. Warning Set the target with care. Make sure you can really build executable programs for that architecture. If you try to compile a system that uses the GNU configure system to configure the build, your target will likely be ignored. For example, if you try to build the aforementioned jikes package with a target of ppc-ibm-aix, to specify IBM???s UNIX, called AIX, on a PowerPC architecture, you will see the target ignored as the configure system detects that it's running on Linux on an i686 architecture. For example: $ rpmbuild -bc --target ppc-ibm-aix /usr/src/redhat/SPECS/jikes.spec Building target platforms: ppc-ibm-aix Building for target ppc-ibm-aix Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.94955 + umask 022 + cd /usr/src/redhat/BUILD + LANG=C + export LANG + cd /usr/src/redhat/BUILD + rm -rf jikes-1.17 + /usr/bin/gzip -dc /usr/src/redhat/SOURCES/jikes-1.17.tar.gz + tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd jikes-1.17 ++ /usr/bin/id -u + '[' 500 = 0 ']' ++ /usr/bin/id -u + '[' 500 = 0 ']' + /bin/chmod -Rf a+rX,g-w,o-w . + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.15710 + umask 022 + cd /usr/src/redhat/BUILD + cd jikes-1.17 + LANG=C + export LANG + ./configure CXXFLAGS=-O3 --prefix=/tmp/jikesrpm/usr checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets ${MAKE}... yes checking whether to enable maintainer-specific portions of Makefiles... no checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for g++... g++ As you can see, the command starts out with the target as the platform, but the configure script soon overrides that, as shown at the end of the truncated output. Building RPMs Without an External Spec File Most of the options for the rpmbuild command require an RPM spec file. This file defines all the necessary parameters for the RPM to build. If you???ve downloaded an application, though, you may not have all the information needed to build a spec file. In addition, writing the spec file is the most time-consuming task when building RPMs. If you are lucky, the provider of a given application may have already created a spec file and included the spec file within the source distribution. Options for working with tar archives A special set of options aims toward building RPMs with spec files stored in tar archives, also called tarballs. Tarballs are files combined with the tar (tape archiver) utility and then optionally compressed, usually with the gzip command. Because this format is used so often for UNIX and Linux software, you can use a set of -t options to the rpmbuild command that mimic the -b options. The basic syntax follows: rpmbuild -tBuildStage compressed_tar_archive The -t option is a lot like the -b option covered in Chapter 9, except -t tells rpmbuild to build an RPM from a compressed tar archive instead of from an RPM spec file. You still need a spec file. These commands just assume that the spec file is located within the tar archive. The extra BuildStage option is a special code that tells the rpmbuild command how far to go when building. Table 12-2 lists these options: Table 12-2 Options for building with rpmbuild with tar archives Option Usage -ta Build all, both a binary and source RPM -tb Build a binary RPM -tc Stop after the %build section -tp Stop after the %prep section -ti Stop after the %install section -tl Check the listing of files for the RPM -ts Build a source RPM only Note These command-line options work with a tar archive or a compressed tar archive. The expected archive structure To build a package this way, the tar archive must have enough of an expected structure, such as a configure script and a Makefile with the expected make targets. The most crucial element is that the tar archive must have the package spec file.That???s because the rpmbuild command doesn???t know how to build every program in the universe. Instead, rpmbuild expects to find a spec file to tell it what to do. If you see an error like the following, then your tar archive likely is missing the spec file: $ rpmbuild -tc vixie-cron*tar.gz error: Name field must be present in package: (main package) error: Version field must be present in package: (main package) error: Release field must be present in package: (main package) error: Summary field must be present in package: (main package) error: Group field must be present in package: (main package) error: License field must be present in package: (main package) These errors show expected tags from the missing spec file. Working with Source RPMs Most of your work with the rpmbuild command will likely be to create binary RPMs after you have the sources for an application and a spec file. You can also get a lot of mileage out of source RPMs, whether you build them or download them. Cross Reference Chapter 10 covers the spec file in depth. Because they are RPMs themselves, source RPMs act like other RPMs. For example, you can use the rpm -i command to install a source RPM. This installs the sources provided by the source RPM, not the actual application. Normally, when you install a source RPM on a Red Hat Linux system, the package gets installed into /usr/src/redhat. Note This directory is obviously specific to Red Hat Linux. On other Linux distributions, you'll likely see directories such as /usr/src/OpenLinux for SCO (formerly Caldera) OpenLinux. Installing a source RPM is not exactly the same as installing a binary RPM. For example, the rpm command does not update the RPM database when you install a source RPM. In addition, listing the files in a source RPM only shows the relative paths, not the full paths. Once installation is complete, you can use the rpmbuild command to create a binary RPM from the sources in the source RPM, using the -b command-line options introduced in Chapter 9. The next sections show more shortcuts with source RPMs. Rebuilding binary RPMS from source RPMs As a shortcut, you do not have to install a source RPM to create a binary RPM. Instead, you can build the binary RPM directory using the --rebuild option. The --rebuild option tells the rpmbuild command to rebuild a binary RPM from a source RPM file. The basic syntax is: rpmbuild --rebuild package.src.rpm This command builds a binary RPM out of a source RPM with a minimum of fuss. For example: $ rpmbuild --rebuild unix2dos-2.2-17.src.rpm Installing unix2dos-2.2-17.src.rpm Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.15828 + umask 022 + cd /usr/src/redhat/BUILD + LANG=C + export LANG + cd /usr/src/redhat/BUILD + rm -rf unix2dos-2.2 + /bin/mkdir -p unix2dos-2.2 + cd unix2dos-2.2 + /usr/bin/gzip -dc /usr/src/redhat/S OURCES/unix2dos-2.2.src.tar.gz + tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' ++ /usr/bin/id -u + '[' 500 = 0 ']' ++ /usr/bin/id -u + '[' 500 = 0 ']' + /bin/chmod -Rf a+rX,g-w,o-w . + echo 'Patch #0 (unix2dos-mkstemp.patch):' Patch #0 (unix2dos-mkstemp.patch): + patch -p1 -b --suffix .sec -s + echo 'Patch #1 (unix2dos-2.2-segfault.patch):' Patch #1 (unix2dos-2.2-segfault.patch): + patch -p1 -b --suffix .segf -s + echo 'Patch #2 (unix2dos-2.2-manpage.patch):' Patch #2 (unix2dos-2.2-manpage.patch): + patch -p1 -b --suffix .man -s + perl -pi -e 's,^#endif.*,#endif,g;s,^#else.*,#else,g' unix2dos.c unix2dos.h + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.60650 + umask 022 + cd /usr/src/redhat/BUILD + cd unix2dos-2.2 + LANG=C + export LANG + gcc -O2 -march=i386 -mcpu=i686 -ounix2dos unix2dos.c + exit 0 Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.35128 + umask 022 + cd /usr/src/redhat/BUILD + cd unix2dos-2.2 + LANG=C + export LANG + rm -rf /var/tmp/unix2dos-root + mkdir -p /var/tmp/unix2dos-root/usr/bin /var/tmp/unix2dos- root/usr/share/man/man1 + install -m755 unix2dos /var/tmp/unix2dos-root/usr/bin + install -m444 unix2dos.1 /var/tmp/unix2dos-root/usr/share/man/man1 + /usr/lib/rpm/redhat/brp-compress + /usr/lib/rpm/redhat/brp-strip + /usr/lib/rpm/redhat/brp-strip-comment-note Processing files: unix2dos-2.2-17 Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.12033 + umask 022 + cd /usr/src/redhat/BUILD + cd unix2dos-2.2 + DOCDIR=/var/tmp/unix2dos-root/usr/share/doc/unix2dos-2.2 + export DOCDIR + rm -rf /var/tmp/unix2dos-root/usr/share/doc/unix2dos-2.2 + /bin/mkdir -p /var/tmp/unix2dos-root/usr/share/doc/unix2dos-2.2 + cp -pr COPYRIGHT /var/tmp/unix2dos-root/usr/share/doc/unix2dos-2.2 + exit 0 Finding Provides: /usr/lib/rpm/find-provides Finding Requires: /usr/lib/rpm/find-requires PreReq: rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 Requires(rpmlib): rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 Requires: libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/unix2dos-root Wrote: /usr/src/redhat/RPMS/i386/unix2dos-2.2-17.i386.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.47653 + umask 022 + cd /usr/src/redhat/BUILD + cd unix2dos-2.2 + rm -rf /var/tmp/unix2dos-root + exit 0 Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.47653 + umask 022 + cd /usr/src/redhat/BUILD + rm -rf unix2dos-2.2 + exit 0 With the --rebuild option, the rpmbuild command installs the source RPM for you and then performs the preparation, compile, and installation stages of building a binary RPM. Unless there are errors, you should have a new binary RPM file. When complete, the rpmbuild --rebuild command cleans out the built files in the build directory, as if the --clean option were used. The rpmbuild --rebuild command also removes the installed sources and spec file upon completion. Recompiling binaries from source RPMs If you just want to recompile the files in a source RPM, you can use the --recompile option. The --recompile option tells the rpmbuild command to recompile the binary application from a source RPM. For example: rpmbuild --recompile package.src.rpm This is the same as installing the source RPM and then running rpmbuild -bc --clean with the package spec file. Note There is no difference between --recompile and --rebuild in RPM 4.1. RPM 4.2 fixes this problem. SRPMS? Finding source RPMs Often, source RPMs are abbreviated as SRPMs. In fact, if you see a directory named SRPM or SRPMS, chances are the directory holds source RPMs. (Red Hat uses this convention for its Linux distributions.) The SRPMS directories on Red Hat CD-ROMs or on the Red Hat FTP Internet site, ftp.redhat.com, indicate directories that hold source RPMs. Signing Built RPMs Signing RPMs adds an extra level of trustworthiness to your RPMs. A digital signature helps establish that the package comes from you, really you, and not from someone masquerading as you. Unfortunately, the RPM system requires a bit of set up work before you can sign RPMs. Checking that the GPG software is installed To sign packages, you need to ensure that you have the gpg command installed and configured. To check that this command is installed, use a command like the following: $ rpm -qf `which gpg` gnupg-1.0.7-6 This shows that the command is available. GPG and PGP? Acronyms Explained The RPM documentation uses GPG and PGP pretty much interchangeably, so much so, in fact, that you may think these are typographical errors. Not so. PGP stands for Pretty Good Privacy. Invented by Phil Zimmerman, PGP was originally invented to encrypt e-mail to allow for private communication. Based on a public-key cryptography algorithm, PGP also supports encrypted digital signatures. These signatures allow you to verify that a package you have downloaded really comes from the vendor you think it does. You do this by using the vendor???s public key. GPG stands for GNU Privacy Guard, a free, open-source implementation of PGP from the GNU project. GPG aims to be compatible with the OpenPGP Internet standard as defined in RFC 2440. It started when a number of developers wanted a free implementation. One such free implementation, GPG, allows Linux vendors such as Red Hat to include PGP in their products. So, in a sense, GPG provides PGP. PGP has a long and somewhat troubled history as an open-source product and as a commercial product. See www.philzimmermann.com for background on PGP and its long history. See www.gnupg.org for more details on GPG. Configuring a signature To configure a signature, you first need to create a new key with the gpg command, using the --gen-key option, as shown following: $ gpg --gen-key gpg (GnuPG) 1.0.7; Copyright (C) 2002 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. gpg: Warning: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: keyring `/home2/ericfj/.gnupg/secring.gpg' created gpg: keyring `/home2/ericfj/.gnupg/pubring.gpg' created Please select what kind of key you want: (1) DSA and ElGamal (default) (2) DSA (sign only) (4) ElGamal (sign and encrypt) (5) RSA (sign only) Your selection? 1 DSA keypair will have 1024 bits. About to generate a new ELG-E keypair. minimum keysize is 768 bits default keysize is 1024 bits highest suggested keysize is 2048 bits What keysize do you want? (1024) Requested keysize is 1024 bits Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) You need a User-ID to identify your key; the software constructs the user id from Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) <heinrichh at duesseldorf.de>" Real name: Eric Foster-Johnson Email address: please_no_spam at nospam.com Comment: Example for Red Hat RPM Guide You selected this USER-ID: "Eric Foster-Johnson (Example for Red Hat RPM Guide) <erc at no_spam.com>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O You need a Passphrase to protect your secret key. Enter passphrase: We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++..+++++..++++++++++>++++++++++........+++++ gpg: /home2/ericfj/.gnupg/trustdb.gpg: trustdb created public and secret key created and signed. key marked as ultimately trusted. pub 1024D/01681C24 2002-11-05 Eric Foster-Johnson (Example for Red Hat RPM Guide) <please_no_spam at nospam.com> Key fingerprint = 8C14 A2E9 47D1 301B 2153 7CDF BEE5 9C10 0268 1D24 sub 1024g/1A15D6C8 2002-11-05 You can choose the default options for most choices. You need to enter a real name, an e-mail address, and a pass phrase. Remember the pass phrase. You will need to enter the pass phrase every time you wish to sign a package. Once you have a key, the next step is to set up some RPM macros. There are a number of places you can do this, but using the .rpmmacros file in your home directory is one of the easiest. Edit this file as shown in the following example: %_signature gpg %_gpg_path /home2/ericfj/.gnupg %_gpg_name EricFJ (Eric Key) <erc at no_spam.com> %_gpgbin /usr/bin/gpg Add lines like these to the $HOME/.rpmmacros file. (Create this file if it does not exist.) Cross Reference Chapter 21 covers RPM macros and the $HOME/.rpmmacros file. Inside the file, change the %gpg_path macro to the .gnupg directory under your home directory (or the root user???s home directory). Change the %_gpg_name macro to the name you have entered into the gpg program. Signing with the rpmbuild command The --sign option tells the rpmbuild command to sign the created package. You need to have configured the RPM system for your signature as shown in the previous sections. When you then build an RPM, you will be prompted for your pass phrase prior to the package build. For example, the following shows this prompt (and truncates the rest of the rpmbuild messages that follow): $ rpmbuild -bb --sign xtoolwait-1.2.spec Enter pass phrase: Pass phrase is good. Signing with the rpm command In addition to the --sign option for the rpmbuild command, you can sign packages that have already been created using the rpm command. The --addsign and --resign options generate new signatures and insert them into the passed-in package file. The basic syntax is: rpm --addsign package.rpm rpm --resign package.rpm The --addsign option adds another signature to the RPM. RPM versions prior to 4.1 allowed you to sign a package with multiple keys, which causes problems for automatic verification. Because of that, use the --resign option, which removes the old signature and inserts a new signature into the package. Verifying signatures You can verify the RPM signature to ensure that the package has not been modified since it has been signed. Verification also checks that the package is signed by the key that matches the claimed vendor. To verify the signature in an RPM, use the -K option to the rpm command. The basic syntax is: rpm -K package.rpm Note This is the rpm command, not the rpmbuild command. This command accepts the options shown in Table 12-3 to turn off checking for certain types of signatures. Table 12-3 Options to turn off signature checking Option Usage --nogpg Don???t check for GPG signatures --nomd5 Don???t check for MD5 signatures --nopgp Don???t check for PGP signatures You can also use the --checksig option, which is the same as -K. When you run this command on a package that has a verifiable key, you will see output like the following: # rpm -K xtoolwait-1.3-3.src.rpm xtoolwait-1.3-3.src.rpm: (sha1) dsa sha1 md5 gpg OK This verifies that the package has not been changed from when it was first signed. It also verifies that the signature matches the public key from the vendor of the package. This goes a long ways toward verifying that the package is indeed legitimate. To get more information, add a -v (verbose) option. For example: $ rpm -Kv vixie-cron-3.0.1-69.src.rpm vixie-cron-3.0.1-69.src.rpm: Header V3 DSA signature: OK, key ID db42a60e Header SHA1 digest: OK (ecbb244ab022ecd23114bb1d6c9bdeb74f8d9520) MD5 digest: OK (fb0a75eca1d526d391c36dc956c23bdd) V3 DSA signature: OK, key ID db42a60e If you run this command on a package that does not verify, you???ll see an error like the following: # rpm --checksig xtoolwait-1.3-3.src.rpm xtoolwait-1.3-3.src.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#db42a60e) Items that fail are listed in uppercase, such as DSA, while items that succeed appear in lowercase. In this example, the sha1 and md5 tests succeeded, while the DSA test failed. This failure does not necessarily mean that the package is not legitimate. This failure can mean one of three things: 1.The package was not properly signed in the first place. That is, it is a legitimate package but the package author did not properly sign the RPM. 2.The package has been modified in some way. That is, the package is not legitimate. 3.The RPM system has not been initialized with the public key from the package vendor. From this error, you don???t yet know whether the package is legitimate or not. The first step, though, is to check that you have imported the proper public key from the package vendor. Importing public keys The --import option to the rpm command imports the public key from a given vendor. The format for this key follows: The following public key can be used to verify RPM packages built and signed by Red Hat, Inc. using `rpm -K' using the GNU GPG package. Questions about this key should be sent to security at redhat.com. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org mQGiBDfqVEqRBADBKr3Bl6PO8BQ0H8sJoD6p9U7Yyl7pjtZqioviPwXP+DCWd4u8 HQzcxAZ57m8ssA1LK1Fx93coJhDzM130+p5BG9mYSPShLabR3N1KXdXAYYcowTOM GxdwYRGr1Spw8QydLhjVfU1VSl4xt6bupPbFJbyjkg5Z3P7BlUOUJmrx3wCgobNV EDGaWYJcch5z5B1of/41G8kEAKii6q7Gu/vhXXnLS6m15oNnPVybyngiw/23dKjS ti/PYrrL2J11P2ed0x7zm8v3gLrY0cue1iSba+8glY+p31ZPOr5ogaJw7ZARgoS8 BwjyRymXQp+8Dete0TELKOL2/itDOPGHW07SsVWOR6cmX4VlRRcWB5KejaNvdrE5 4XFtOd04NMgWI63uqZc4zkRa+kwEZtmbz3tHSdWCCE+Y7YVP6IUf/w6YPQFQriWY FiA6fD10eB+BlIUqIw80EqjsBKmCwvKkn4jg8kibUgj4/TzQSx77uYokw1EqQ2wk OZoaEtcubsNMquuLCMWijYhGBBgRAgAGBQI36lRyAAoJECGRgM3bQqYOhyYAnj7h VDY/FJAGqmtZpwVp9IlitW5tAJ4xQApr/jNFZCTksnI+4O1765F7tA== =3AHZ -----END PGP PUBLIC KEY BLOCK----- Note For reasons of space, this is not a complete key. You need to pass the name of the text file that holds the key to the rpm --import command, as shown following: rpm --import key_file Note You must be logged in as the root user to import keys. For example: # rpm --checksig xtoolwait-1.3-3.src.rpm xtoolwait-1.3-3.src.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#db42a60e) # rpm --import RPM-GPG-KEY # rpm --checksig xtoolwait-1.3-3.src.rpm xtoolwait-1.3-3.src.rpm: (sha1) dsa sha1 md5 gpg OK This example shows an error message when trying to verify the key. Then, after importing the Red Hat public key, the verification works. If, after importing this key, you still have problems, you can assume there are problems with the package. Many administrators will refuse to install such packages. Warning You should be careful with packages that have signatures that do not verify. To list the available keys, use a command like the following: $ rpm -qa | grep -i gpg gpg-pubkey-db42a60e-37ea5438 This example shows one key installed. Note You can erase this key as if it were a package, using the rpm -e command. Getting the Red Hat public key Strangely enough, the Red Hat public key is not installed when you install Red Hat Linux 8.0. If you need the key, the Red Hat public key is available on the root directory of all Red Hat Linux CD-ROMs, as shown in the following listing: $ ls /mnt/cdrom/ EULA GPL README RedHat/ RPM-GPG-KEY SRPMS/ TRANS.TBL Simply copy the RPM-GPG-KEY file to get the public key. Then use the rpm --import command with this key file. Note You can also download this key file from the Red Hat FTP site, at ftp://ftp.redhat.com/pub/redhat/linux/8.0/en/os/i386/. Summary This chapter covers options for the rpmbuild command that allow you to achieve a finer grain of control over how the command works. For example, the --short-circuit option tells the rpmbuild command to build just the stages you ask for. This helps when you have problems in one area of building an RPM and don???t want to start over each time you try to see if the problem is solved. The rpmbuild command also supports a set of -t options that work like the -b options, except the -t options try to build an RPM from a tar archive of sources (a tarball) instead of an RPM spec file. In this case, the rpmbuild command tries to work without a spec file. The --rebuild option tells the rpmbuild command to install a source RPM, build the binary RPM, and clean out the installed source RPM. This provides quite a shortcut for installing binary RPMs from source RPMs. RPMs should be signed to provide an extra level of authentication. This system isn???t perfect, but it helps you verify that a package is from the person it says it is from and that the package has not been modified. You can check the signature on RPM packages you download. You can also, with some configuration, sign the packages you create. From fedora-docs-commits at redhat.com Tue Oct 4 02:00:09 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 22:00:09 -0400 Subject: rpm-guide rpm-guide-rpm-evolution-en.xml,NONE,1.1 Message-ID: <200510040200.j9420957001012@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv987 Added Files: rpm-guide-rpm-evolution-en.xml Log Message: --- NEW FILE rpm-guide-rpm-evolution-en.xml --- RPM Feature Evolution Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). Although RPM implementations are largely compatible from version to version, RPM packagers must remember that RPM is a still-evolving program and that its developers are adding features to it with each new version. When producing RPM package files, packagers must keep in mind the audience that will be using the final RPM package files. They must decide which versions of RPM they intend the package to be used with and must use only the lowest common denominator set of features implemented in the oldest of the RPM versions they are targeting. As a quick reference, keep in mind the RPM features noted here and the RPM version in which they are introduced. In considering these revisions of RPM, the main releases of interest are RPM 2.5, RPM 3.0.5, RPM 4.0.4, and RPM 4.1. RPM 2.5 is not widely used anymore; packages should target RPM 2.5 only if the intention is for the RPM package to install using absolutely all RPM versions. RPM 3.0.5 is the final release of the 3.x series of RPM. It was the release of RPM shipped with Red Hat Linux 6.2 and older releases. It is still in wide use by other vendors as well. Cobalt???s Linux distributions use an RPM implementation version based on RPM 3.0.5, for example. (Red Hat Linux was upgraded to RPM 4 via an errata.) RPM 4.0.4 was used with the 7.x releases of Red Hat Linux, and RPM 4.1 first shipped with Red Hat Linux 8.0. Packages produced targeting RPM 3.0.5 should work with nearly all implementations of RPM still in use today. Packages produced targeting RPM 4.0.4 or RPM 4.1 will work only with recent RPM implementations. RPM 2.5 is the oldest version of RPM that can, by any stretch of the imagination, still be considered in use. With RPM 2.5, most of the basic RPM features were in place, as well as more advanced functions such as triggers and support for internationalization of Summary:, Description:, and Group: tags in the RPM file header. RPM 2.5 was also the first version of RPM to use the RPM version 3 RPM file format. RPM 2.5.3 added support for Epochs to the RPM header, implementing RPMTAG_EPOCH. RPM 2.5.4 introduced the %license and %readme file types, which can be used in the RPM spec file to indicate license and README files. RPM 2.5.6 added support for usage of the Epoch: keyword in the RPM spec file, allowing you to force an Epoch for your package. The Epoch: keyword replaced the older Serial: keyword, which semantically behaved similarly. RPM 2.5.7 enforced the previously implied standard that the "-" character should not be used within the Version or Release fields in the RPM spec file. RPM 2.90 introduced support for signing and verifying RPM package files using GPG, the GNU Privacy Guard. RPM 2.91 allowed the usage of Provides: directives that defined absolute paths to provided files. Prior to RPM 2.91, Provides: could be used only for listing provided capabilities, not for using statements like Provides: /path/to/file to indicate provided files. RPM 3.0.2 permitted usage of multiple Provides: lines for the first time, eliminating the need to combine all provided capabilities and files on the same line in the spec file. RPM 3.0.3 added support for versioned dependencies. Prior to RPM 3.0.3, spec files could indicate that a package required another package or provided a specific capability, but they could not indicate the acceptable versions of the required package or which version of the capability the package provided. RPM 3.0.4 introduced CompressedFileNames support to RPM. Prior to RPM 3.0.4, RPM packaged the absolute paths of all archived files within the package file. Package file headers contained statements such as fileName #0: /usr/bin/ar fileName #1: /usr/bin/as fileName #2: /usr/bin/gasp fileName #3: /usr/bin/gprof With CompressedFileNames support, the RPM package file header instead stores the directory name, then just the base name of files within that directory. Package file headers now contain statements such as the following for a given directory with a number of files within that directory: dirName #0: /usr/bin baseName dirIndex #0 ar 0 #1 as 0 #2 gasp 0 #3 gprof 0 Each file entry now holds the file's base name within the directory, as well as an index number that refers to the directory entry. Since packages typically contain lots of files within the same directory, CompressedFileNames support results in significant memory savings when processing packages for installation. RPM 3.0.5 added PayloadIsBzip2 support to RPM, allowing the data payload of RPM package files to be compressed using bzip2 instead of gzip. Even though RPM now supports bzip2 compression of package files, this feature is rarely used in practice, since significantly more memory and time is required to install bzip2-compressed RPM package files than to install gzip-compressed RPM package files. RPM 3.0.5 also added support to RPM for manipulating existing RPM version 4 file format packages; packages produced with RPM 3.0.5 can only be RPM version 3 file format, however. RPM 4.0 implemented several significant changes to RPM. RPM 4.0 created package files using RPM version 4 package file format. RPM 4.0 also switched from Berkeley db 1.85 to Berkeley db 3.1 as the database program used for creation and manipulation of the RPM database. The RPM package database file was renamed as well. The db3 package database file is /var/lib/rpm/Packages, and the older db1 package database file was /var/lib/rpm/packages.rpm. Changing the package database file name allowed old and new versions to co-exist if necessary, simplifying upgrades from older RPM releases to the new RPM 4.0 release. RPM 4.0 also introduced the PayloadFilesHavePrefix feature, changing the way archived files are named within the RPM package file. RPM package files contain a cpio archive of files. Prior to RPM 4.0, file names in the cpio archive were stored without a root prefix. With PayloadFilesHavePrefix, all file names within the cpio archive files now have a root prefix, such as ./usr/bin/ar. This modification made it possible for RPM package files to contain the root directory, ???./???. Additional sanity-checking was added to the RPM 4.0 spec file parser; beginning with 4.0, RPM no longer allows dangling symbolic links that contain the BuildRoot. This change eliminates a class of common mistakes made when producing RPMs. Finally, RPM 4.0 implicitly generates Provides: directives; whenever a package header is read, the Provides: directive Provides: %{name} = %{epoch}:%{version}-%{release} is automatically generated, ensuring that all packages explicitly provide themselves as a capability and removing the need to provide self-capabilities within the package spec file. RPM 4.0.2 introduced the use of SHA-1 message digests to validate RPM header regions. RPM 4.0.3 added the %dev(type,major,minor) spec file directive, allowing creation of device nodes. In addition, the %configure spec file directive now supported --target and ???host, simplifying cross compilation when using RPM. The %files directive was extended by adding the %exclude subdirective that could be used to exclude files from inclusion. Finally, RPM 4.0.3 switched back to creating package files in RPM version 3 package file format by default, although it still supports RPM version 4 package file format as well. RPM 4.0.4 provided PartialHardlinkSets support. RPM package files are sometimes created which contain multiple copies of the same file, stored as hard links to save space. Prior to RPM 4.0.4, RPM has always treated collections of hard links as an all-or-nothing proposition; all hard links were created, or else none were created. This behavior posed problems when some hard links in a set were tagged with attributes such as %doc or %lang, since rpm commands make it possible to install an RPM package file without installing any files with %doc attributes. Prior to RPM 4.0.4, doing so would break the hard link set, preventing creation of all hard links in the set. PartialHardlinkSet corrects this problem by allowing successful creation of subsets of the hard link set. RPM 4.0.4 also provided automatic generation of Perl module Requires: directives. find-requires now parses all packaged Perl scripts, generating any determined dependencies. In addition, RPM 4.0.4 provides transaction support for RPM. RPM 4.1 adds separate header DSA and RSA signatures, allowing verification of RPM package headers. Finally, when considering the RPM features required by your prepared package, remember that some required RPM features are specified manually within the package spec file, while others are automatically added by RPM during the RPM package file build process. For example, usage of versioned Requires: directives in a spec file will make the resulting RPM package file correctly installable only by RPM release 3.0.3 or later. Similarly, the preparation of any package using RPM release 4.0 or later will automatically produce RPM package files that can only be manipulated by releases of RPM that support the PayloadFilesHavePrefix feature. In the first case, you chose to produce packages that worked with RPM release 3.0.5 or later but not with RPM release 2.5 by including a new directive in the package spec file. In the second case, however, you did not explicitly produce packages that work only with recent RPM releases. The simple fact that you built your RPM package using RPM release 4.0 means that you automatically used features that only RPM 4.0 and later releases understand. These automatic internal requirements are quite common in the later versions; as a result, the best practice is to decide the oldest version of RPM that you wish to support, then to build all packages using that version of RPM, keeping its feature set in mind as you prepare and build the packages. From fedora-docs-commits at redhat.com Tue Oct 4 02:00:43 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 22:00:43 -0400 Subject: rpm-guide rpm-guide-rpm-overview-en.xml,NONE,1.1 Message-ID: <200510040200.j9420heI001041@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv1023 Added Files: rpm-guide-rpm-overview-en.xml Log Message: --- NEW FILE rpm-guide-rpm-overview-en.xml --- RPM Overview Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Chapter *Understanding the package file *Querying the RPM database *Running RPM commands Working with RPM packages, files, commands, and databases can be complicated. There are thousands of files, for hundreds if not thousands of packages, installed on your system. You need some way to manage it all. The RPM system can help you do that. This chapter provides an overview of the components that make up the RPM system for package management: package files, databases, and RPM commands. Understanding the Package File RPM provides for installing, upgrading and removing packages. Typically, each package is an application and all the necessary files associated with that application. For example, the Apache Web server comes with a number of configuration files, a large set of documentation files, and the Apache server itself. All of this fits into one RPM package. One of the main advantages of the RPM system is that each .rpm file holds a complete package. For example, the following file holds the xcopilot package: xcopilot-0.6.6-3.i386.rpm Based on the naming conventions discussed in Chapter 2, this package represents xcopilot package, version 0.6.6, third build of an RPM package, for i386 (Intel) architecture systems. With a single command, you can copy an .rpm file to another Linux system and install it, getting the complete contents of the package, or you can use other commands to remove or update the package. RPM file format RPM files hold a number of tagged data items and a payload, the files to install on your system. The tagged data items describe the package and can contain optional features. For example, the NAME tag holds the package name. The optional PRE tag holds a pre-installation script, a script that the rpm command runs prior to installing the files in the package payload. Under the covers, RPM package files contain four sections. The first is a leading identification area that marks the file as an RPM package (created with a particular version of the RPM system). The remaining sections are the signature, the tagged data (called the header), and the payload. Each of these sections has important information about the package, although the payload section contains the actual content of the package. *The signature appears after the lead or identifier section, which marks the file as an RPM file. Like your signature when you sign a check, the RPM signature helps verify the integrity of the package. No, the signature doesn???t check for bugs in software applications. Instead, it ensures that you have downloaded a valid RPM archive. The signature works by performing a mathematical function on the header and archive sections of the file. The mathematical function can be an encryption process, such as PGP (Pretty Good Privacy), or a message digest in MD5 format. *The header contains zero or more tagged blocks of data that pertain to the package. The header contains information such as copyright messages, version numbers, and package summaries. *The payload section contains the actual files used in the package. These files are installed when you install the package. To save space, data in the archive section is compressed in GNU gzip format. Once uncompressed, the data is in cpio format, which is how the rpm2cpio command (introduced in the "Other RPM commands" section later in this chapter) can do its work. Binary RPMs and Source RPMs There are two main types of RPM packages: binary (or applications) and source. A binary RPM has been compiled for a particular architecture. For example, the Apache Web server compiled for an Intel Pentium, or i586, architecture won???t work on a Sharp Zaurus, which runs an Intel ARM processor. To run on both systems, you would need two separate packages: one for the Pentium i586 and one for the ARM. In addition to binary RPMs, you can get source code RPMs. These RPMs are packages that provide the source code for other packages. Sounds kind of circular, doesn???t it? binary RPMs Binary RPMs hold complete applications or libraries of functions compiled for a particular architecture. Most binary RPMs contain complete applications, such as the Apache Web server or the AbiWord word processor. These application binary RPMs usually depend on a number of system libraries which are, in turn, also provided by binary RPMs. Cross Reference Chapter 8 covers a number of locations where you can find RPM applications galore. Your Linux installation CDs are also a great source for applications. Most Linux distributions come with more applications than you can imagine using. Although most binary RPMs are complete applications, others provide libraries. For example, the Simple DirectMedia Layer library (SDL), which provides really cool graphics for many games, can be packaged as an RPM file. A number of programs, mostly games, use this library for enhanced multimedia such as rich graphics. RPMs that provide libraries allow multiple applications to share the same library. Typically, the libraries are packaged into separate RPMs from the applications. In addition to binary RPMs that hold applications or libraries compiled for a particular architecture, RPM supports the concept of platform-independent binary RPMs. These platform-independent RPMs, called noarch as a shorted form of ???no architecture??? dependencies, provide applications or libraries that are not dependent on any platform. Applications written in Perl, Python, or other scripting languages often do not depend on code compiled for a particular architecture. In addition, compiled Java applications are usually free of platform dependencies. Source RPMs The xcopilot package, mentioned previously, contains the xcopilot application used for synchronization with Palm handheld devices. The source code used to create this application is stored in an xcopilot source RPM, for example: xcopilot-0.6.6-3.src.rpm By convention, source RPMs have a file name ending in .src.rpm. Source RPMs should contain all the commands, usually in scripts, necessary to recreate the binary RPM. Having a source RPM means that you can recreate the binary RPM at any time. This is a very important goal of the RPM system. Note Source RPMs have nothing to do with open-source software licenses. Linux is famous for being an open-source operating system. In RPM terms, that means the source code for the Linux kernel and most Linux applications are freely available as source RPMs. But you can also make source RPMs for proprietary programs. The key issue is that you are unlikely to distribute the source RPMs for proprietary packages. Furthermore, a number of open-source applications are not available as source RPMs. That's a shame, since source RPMs would make these applications easier to install. While source RPMs hold the commands necessary to create the binary RPM, there may be differences in your Linux environment that would result in rebuilding a binary RPM that is different from the original binary RPM. For example, the compile scripts for some packages may add in optional code depending on which libraries or which versions of libraries are found on your system. Chapter 14 covers many issues in creating RPMs, and Chapters 19 and 20 cover issues related to other versions of Linux and other operating systems, respectively. If you follow the guidelines when making your own RPMs, you should result in source RPMs that reproduce binary RPMs as consistently as possible. Querying the RPM Database The RPM database holds information about all the RPM packages installed on your system. You can use this database to query what is installed, to help determine if you have the latest versions of software, and to verify that your system is properly set up, at least from a packaging point of view. The RPM database itself is stored in the directory /var/lib/rpm, and should contain files like the following: Basenames Conflictname __db.001 __db.002 __db.003 Dirnames Filemd5s Group Installtid Name Packages Providename Provideversion Pubkeys Requirename Requireversion Sha1header Sigmd5 Triggername Cross-reference Chapter 5 covers the database in more detail. These files make up the RPM database. The file __db.001 and similar files are lock files used by the RPM system. The other files are databases in Berkeley DB format. The most important file is Packages. The Packages file contains the header tag information for each package indexed by an index number for each package. This number slowly grows with time. The other files, such as Name, Providename, and Group, exist to speed access to particular types of information. Treat your RPM database with care. Back up the files, especially after upgrading, installing, or removing packages. Note Only the Packages file is essential. You can recreate the rest of the files using the rpm --rebuilddb command, introduced in Chapter 5. Running RPM Commands The primary RPM command is simply rpm. One of the original goals of the RPM system is providing ease of use. In support of this goal, just about everything you want to do with the RPM system can be done with this one command. For most usage, the command-line parameters to the rpm command determine the actions it should take. Working with the rpm command The rpm command performs the most common package-management functions, along with a host of uncommon functions as well. Table 3-1 lists the main operations you can perform with the rpm command and the command-line options to specify the given operations. Table 3-1 The main rpm operations Operation Short Option Long Option Upgrade/install -U --upgrade Install -I --install Remove -e --erase Query -q --query Verify -V --verify Check signature -K --checksig Freshen (upgrade) already-installed package -F --freshen Initialize database None --initdb Rebuild database None --rebuilddb Using Table 3-1 as a guide, you can explore the options to the rpm command. To install or upgrade a package, use the -U command-line option: # rpm -U filename.rpm For example, to install the xcopilot RPM used as an example in this chapter, run the following command: # rpm -U xcopilot-0.6.6-3.i386.rpm To get extra feedback, you can use a command like the following, with the -h and -v options in conjunction with the ???U option: # rpm -Uhv xcopilot-0.6.6-3.i386.rpm When you run this command you will see more output than the default, which is no output unless there are errors. With the ???h option, the rpm command will print a series of hash marks, #, to provide feedback that the command is still running. With the ???v option, the rpm command provides more verbose messages. Note The most common command to install a package is: # rpm -Uhv package_file.rpm This command upgrades a package with extra output. If the package has not been installed, this command installs the package. See Chapter 4 for more on upgrading and installing. To remove a package (called erase in RPM terminology), use the ???e command-line option: # rpm ???e package_name Note Notice that you install a package file using the file name that ends in .rpm, but uninstall or erase a package without the .rpm extension. This is because you install RPM files, but once installed, you work with the installed packages. The file name and the package name do not have to correspond, but typically (and sanely) they have the same base name. To list every RPM package installed on your system, use a command like the following. $ rpm ???qa Expect to wait while this command completes. Most Linux systems have numerous packages installed, which will result in many lines of output. To better see the output, you can pipe this command to the more command, as shown following: rpm ???qa | more You will then see the package listing one screen at a time. Cross Reference Appendix A lists all the options for the rpm command. Other RPM commands In addition to rpm, the RPM system includes a few more commands, including rpmbuild and rpm2cpio. The rpmbuild command helps build RPM packages. I describe its usage in depth in Part II of this book. The rpm2cpio command exports an RPM package file into the format that the cpio command expects. The cpio command works with many tape-backup packages. You can also take advantage of the fact that cpio can list the individual files in a cpio archive or extract files. To list the files in an RPM package, use a command like the following: $ rpm2cpio package_file.rpm | cpio ???t For example, the following command lists all the files in the xcopilot package: $ rpm2cpio xcopilot-0.6.6-3.i386.rpm | cpio ???t /etc/X11/applink/Applications/xcopilot.desktop usr/bin/xcopilot usr/doc/xcopilot-0.6.6 usr/doc/xcopilot-0.6.6/README usr/include/X11/pixmaps/xcopilot.xpm usr/include/X11/pixmaps/xcopilot2.xpm 3120 blocks The rpm2cpio command can also help if you want to extract a single file from the RPM package, using the cpio ???ivd command-line options, as follows: $ rpm2cpio xcopilot-0.6.6-3.i386.rpm | cpio ???ivd usr/doc/xcopilot-0.6.6/README This command will output local usr/doc/xcopilot-0.6.6 subdirectories and the README file located under usr/doc/xcopilot-0.6.6. The ???i option tells cpio to extract files. The ???d option tells cpio to make any local subdirectories as needed (usr/doc/xcopilot-0.6.6, in this example), and the ???v option asks cpio to politely output verbose messages about what it does. Of course, verbose is in the eye of the beholder; with many Unix and Linux commands, verbose output is still somewhat terse. Summary The RPM files, the RPM database, and the RPM commands are the primary components that make up the RPM system. This chapter introduces you to the format and types of RPM files, the importance of maintaining the database, and the basic rpm command. The next chapter covers the most frequently used RPM commands. These commands allow you to install, uninstall, and update RPM packages. From fedora-docs-commits at redhat.com Tue Oct 4 02:02:16 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 22:02:16 -0400 Subject: rpm-guide rpm-guide-scripting-en.xml,NONE,1.1 Message-ID: <200510040202.j9422GXJ002435@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv2417 Added Files: rpm-guide-scripting-en.xml Log Message: --- NEW FILE rpm-guide-scripting-en.xml --- Automating RPM with Scripts Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Chapter *Deciding when to program and when to script *Examining RPM files with scripts *Querying the RPM database with scripts The rpm command provides a very high-level view of package management. Most of the operations you need to perform require only a single invocation. Some of the command-line options to the rpm command tend to get very complex, however, especially for detailed queries. That???s where scripting can help. This chapter covers scripting, specifically shell scripting, with the rpm command, especially for newcomers to Linux scripting Scripting Scripting allows you to quickly write new commands in a language, called a scripting language, that can help automate your work. Used heavily by system administrators and lightly by software developers, scripts can help remove some of the tedium from your day-to-day tasks. Scripts can also hold the complex query formats used with the rpm command so you don???t have to remember them. Scripts start out as text files. These text files hold commands in the scripting language. Most of these script file commands run commands installed on your system, such as rpm. To run a script, invoke a command, called an interpreter, that reads in the script file and executes the commands inside the script. Programming is usually considered different from scripting, even though there are many similarities. Programs start out as text files. These text files hold commands in the programming language and sometimes, not often, calls to commands installed on your system. Programs generally involve more work than scripts and are generally larger, containing more commands. Furthermore, most programs need to be compiled. A separate command parses the program text files and generates some form of machine code. Multiple pieces of a program may be linked together to form a command you can call from your shell prompt. Some programming languages, such as Java or C#, are compiled to a generic bytecode format. A compiled Java program, for example, is the same no matter what the architecture. To run such a program, you need a runtime engine such as the java command provides. (Runtime engine is a fancy term for interpreter.) Such differences between scripting and programming sometimes get in the way of performing real work. For example, I once worked with a group of people who were convinced that they were not programmers. They felt that programming was an art that was far beyond them. Yet, they wrote hundreds of kilobytes of scripts to create a sophisticated graphical interface for a Computer-Aided Design system. In my mind, they were programming (and doing quite well at it). In their minds, though, there was a clear distinction between scripting at mdwhat they could do at mdand programming, which was beyond them, they thought. Don???t get caught up in this. Use the right tool for the job. Distinguishing Scripting Languages from Programming Languages Experts differ regarding what defines a scripting language and what defines a programming language. It???s clear that languages such as Python blur the old distinction between programming and scripting. Originally, scripting was writing small files of commands that invoked other system commands. For example, you could write a script that wraps the Linux file command. Scripts were executed by scripting-language interpreters that parsed each command one at a time and then executed the command. Modern scripting languages, such as Tcl, are parsed at runtime and compiled into an internal bytecode format. Once compiled, there is no real difference from a language associated with programming such as Java. With a scripting language *You generally don???t have to compile the script in advance. The scripting language interpreter may compile the program, often to an internal byte code, but you don???t have to invoke a compiler as a separate step. *The facilities of the language generally provide a higher level and more abstract level of interaction with the system than with programming languages. For example, writing socket-based networking code in Tcl requires a lot less code than writing the same code in a programming language such as C. Tcl provides a more abstract view of networking; therefore, your code is a lot simpler. *The commands in the scripting language are mostly the commands available to you on the command line. Scripting languages introduce their own commands, too. *The language is generally identified as a scripting language. This is more consensus than anything else. Forth is considered an interpreted programming language, while Perl is considered a scripting language. Table 15-1 lists some of the more common scripting and programming languages. Note that these are the generally-accepted categories for these languages, not hard and fast rules. This should not stop you, for example, from writing programs in Perl or Python. The distinctions between programming and scripting have blurred in recent years. Table 15-1 Common Scripting Languages and Common Programming Languages Scripting Languages Programming Languages Bash (Bourne Again shell) Csh (C shell) JavaScript Ksh (Korn shell) Lua MS-DOS batch files Perl Python Ruby Sh (Bourne shell) Tcl Assembler BASIC C C++ C# FORTRAN Forth Java LISP Modula-2, Modula-3 Oberon Pascal Deciding When to Program and When to Script Just as the distinction between programming and scripting languages has blurred in the last few years, so have the guidelines for when you should program and when you should script. The simplest rule remains, though: Use whatever techniques make you productive. In the end, no one really cares if you call it a program or a script. Even so, these guidelines may help: *If you have to perform a lot of operations on a lot of RPMs, a program will likely perform much faster than a script that calls the rpm command over and over. *If the task is relatively simple, scripting generally works best. *If you are more experienced with a particular language, use it. *If you need to perform complex operations, perhaps involving transactions, a program is probably the right way to go. *In many cases, programming languages work better for creating graphical user interfaces, although Python and Perl offer graphical user interface toolkits, such as Perl/Tk or PyQt. There isn???t one right way to do it. Pick what works best for you. Cross Reference This chapter covers shell scripting. Chapter 16 covers C programming. Chapter 17 covers Python scripting and programming, and Chapter 18 covers Perl scripting. Shell Scripting Basics For newcomers to scripting, don???t worry. A script, in this case a shell script, is merely a text file with commands mostly the same as the commands you can type at the keyboard. I???ll point out the differences. The following sections quickly introduce scripting for those new to this venture. Writing a script For your first venture, enter the following script into a text file: rpm -qa | grep rpm This script has a two-part command. The rpm ???qa part queries all RPM packages, as covered in Chapter 4. The grep rpm part finds only packages with rpm in their names. This is a very simple script, but it can serve to show how to work with scripts. Save this file under the name listrpmpkgs, since this script lists RPM packages. Note If you???re new to Linux, you???ll notice there???s no program named Notepad.exe. There are, though, a plethora of Linux text editors to choose from. See Appendix F for a listing of Linux text-editing tools. Running a script Once you???ve entered a script, you can run it with the sh command, as shown following, passing the name of your script to the sh command: $ sh listrpmpkgs librpm404-devel-4.0.4-8x.27 librpm404-4.0.4-8x.27 rpm404-python-4.0.4-8x.27 rpm-4.1-1.06 rpm-devel-4.1-1.06 gnorpm-0.9-1 rpm-python-4.1-1.06 redhat-rpm-config-8.0-1 rpm-build-4.1-1.06 rpmrebuild-1.0-0 Type the command you have placed in your script at the command line. There should be no difference in the output. For example: $ rpm -qa | grep rpm librpm404-devel-4.0.4-8x.27 librpm404-4.0.4-8x.27 rpm404-python-4.0.4-8x.27 rpm-4.1-1.06 rpm-devel-4.1-1.06 gnorpm-0.9-1 rpm-python-4.1-1.06 redhat-rpm-config-8.0-1 rpm-build-4.1-1.06 rpmrebuild-1.0-0 Problems running scripts The previous script example required the sh program, a Linux shell, to run the script. You also had to have the script file, such as listrpmpkgs, available. So, if you have stored the file in /home2/bin, to run the script, use the following command: $ sh /home2/bin/listrpmpkgs That???s not very convenient. Furthermore, you always have to remember where you stored the script file listrpmpkgs. To make this command work better, you can turn your script into a command. Turning a script into a command To turn a script into a command, do three simple things: 1.Add a special magic comment to the start of the file so Linux recognizes your text file as a command script. 2.Change the permissions on the file so that it is marked as executable. 3.Copy the file to a directory located in your command path. Shell scripts use a # to indicate a comment, text intended for human readers that can help explain the purpose of the script. By convention, Linux shells use a #! comment in the first line of a script file as a special marker that indicates the file is a shell script. The text that comes after the #! holds the name of the command that should be used to run the script. In almost all cases, that command should be /bin/sh for a shell script. So edit the listrpmpkgs script again, and add the magic comment so that the file reads as follows: #!/bin/sh rpm -qa | grep rpm Make sure the #! comment starts at the beginning of the first line. Next, change the permissions on the script to mark it as an executable program. Use the chmod command to do this. The chmod command changes the file permissions. To see the permissions, run the ls ???l command before changing the permissions: $ ls -l listrpmpkgs -rw-rw-r-- 1 ericfj ericfj 31 Nov 7 20:02 listrpmpkgs The first set of characters, the -rw-rw-r--, indicate the permissions in three batches: permissions for the file owner, the owner???s group of users, and world (everyone else). The rw means read and write, and the r alone means read only for everyone not the owner and not in the owner???s group. To add the permission to execute the file for the file owner only, use the following command: $ chmod u+x listrpmpkgs In this command, the u stands for the user who owns the file (for historical reasons, an o stands for others, not owner). The +x means add the x permission, short for execute permission. After running this command, you can see the revised permissions. $ ls -l listrpmpkgs -rwxrw-r-- 1 ericfj ericfj 31 Nov 7 20:02 listrpmpkgs Cross Reference Use the man chmod command to see more information on this command. You now have a command you can run locally. For example: $ ./listrpmpkgs librpm404-devel-4.0.4-8x.27 librpm404-4.0.4-8x.27 rpm404-python-4.0.4-8x.27 rpm-4.1-1.06 rpm-devel-4.1-1.06 gnorpm-0.9-1 rpm-python-4.1-1.06 redhat-rpm-config-8.0-1 rpm-build-4.1-1.06 rpmrebuild-1.0-0 The next step is to copy the file to a directory in your system command path. To see which directories are in your path, run the following command: $ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/ericfj/bin:/usr/java/j2sdk1.4.0_01/bin Pick one of these directories. The /usr/local/bin directory is a common place to share locally created commands. If this is a personal command for your own use only, a directory under your home directory will be better. In this example, the /home/ericfj/bin is one such directory. Copy the script file to a directory in your command path, and you are ready to go. Note If you use the C shell, csh, or the T C shell, tcsh, you need to run the rehash command to tell the shell to look again at the set of commands available in your command path. Enter the following command: $ listrpmpkgs librpm404-devel-4.0.4-8x.27 librpm404-4.0.4-8x.27 rpm404-python-4.0.4-8x.27 rpm-4.1-1.06 rpm-devel-4.1-1.06 gnorpm-0.9-1 rpm-python-4.1-1.06 redhat-rpm-config-8.0-1 rpm-build-4.1-1.06 rpmrebuild-1.0-0 You have now extended the Linux command set with your own command. Note Windows users may be used to the convention that program file names end in .exe and scripts end in .bat or .cmd. When you run these programs or scripts, you don???t include the extension, exe, .bat, or .cmd. With Linux and UNIX, though, the full file name is important, so if you name your script rpminfo.bat, you must type rpminfo.bat each time you run the script. That???s why most Linux programs and scripts have no filename extension. If you want to share your script with others, you should give them the right to execute it as well. You can do that with the following command: $ chmod a+x listrpmpkgs In this case, the a stands for all users. Passing command-line options to your script The listrpmpkgs script used so far isn???t very useful. It performs one command and that???s it. We cannot customize it without writing a new script. One way to make a script more flexible is to allow it to use command-line options. Just like the rpm command accepts a zillion options, you can make your scripts accept options. Shells define special variables for the command-line options passed to the shell. Table 15-2 lists these options. Table 15-2: Shell variables for command-line options Variable Holds $0 The name of the script itself, from the command line $1 The first option $2 The second option $3 The third option $4 The fourth option $5 The fifth option $6 The sixth option $7 The seventh option $8 The eighth option $9 The ninth option $* All command-line options $# Holds the number of command-line options Note Use $#argv in place of $# if you use the C shell to run your scripts. You can use these variables to allow the user to pass the text to search for, instead of always searching for rpm. With this addition, your new script, renamed rpmgrep, follows in Listing 15-1: Listing 15-1: rpmgrep #!/bin/sh rpm -qa | grep $* This script now expects a command-line option that holds the text to search for. Mark this script as an executable; then you can run it as follows: $ ./rpmgrep python python-devel-2.2.1-17 gnome-python2-gtkhtml2-1.99.11-8 gnome-python2-canvas-1.99.11-8 gnome-python2-1.99.11-8 rpm404-python-4.0.4-8x.27 orbit-python-1.99.0-4 gnome-python2-bonobo-1.99.11-8 gnome-python2-gconf-1.99.11-8 libxslt-python-1.0.19-1 libxml2-python-2.4.23-1 python-optik-1.3-2 python-2.2.1-17 rpm-python-4.1-1.06 mod_python-3.0.0-10 python-tools-2.2.1-17 If you want to make this command available, copy it to a directory in your command path as described in the preceding section. Examining RPM Files When you work with a lot of RPM files, you???ll find that you run the same commands over and over again for each new package you get. For example, you may want to see what capabilities a package requires. You can type in the rpm command each time, or write a short shell script with the necessary command-line options. Listing 15-2 shows this script. Listing 15-2: rpmdepend #!/bin/sh rpm -qp --requires $* This script expects the name of an RPM package file. Run the command as follows: $ rpmdepend vim-common-6.1-14.i386.rpm rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 /bin/sh /usr/bin/awk libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) Another common task I perform involves listing all the files in an RPM along with the descriptive information on the package. This can really help, since so many Linux packages have nondescriptive names such as dia and anaconda. Listing 15-3 shows the rpminfo script. Listing 15-3: rpminfo #!/bin/sh rpm -qilp $* | less This script lists a potentially long set of lines, so the script pipes the output to the less command. For example: $ ./rpminfo perl-XML-Dumper-0.4-22.noarch.rpm Name : perl-XML-Dumper Relocations: /usr Version : 0.4 Vendor: Red Hat, Inc. Release : 22 Build Date: Tue 06 Aug 2002 01:53:30 PM CDT Install date: (not installed) Build Host: vegeta.devel.redhat.com Group : System Environment/Libraries Source RPM: perl-XML-Dumper-0.4-22.src.rpm Size : 10015 License: GPL Signature : DSA/SHA1, Tue 06 Aug 2002 02:11:39 PM CDT, Key ID fd372689897da07a Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://www.cpan.org Summary : Perl module for dumping Perl objects from/to XML Description : XML::Dumper dumps Perl data to XML format. XML::Dumper can also read XML data that was previously dumped by the module and convert it back to Perl. Perl objects are blessed back to their original packaging; if the modules are installed on the system where the perl objects are reconstituted from xml, they will behave as expected. Intuitively, if the perl objects are converted and reconstituted in the same environment, all should be well. /usr/lib/perl5/vendor_perl/5.8.0/XML/Dumper.pm /usr/share/man/man3/XML::Dumper.3pm.gz I use this script so that I know what files a package wants to install. Querying the RPM Database In addition to querying RPM files, you can script the commands you use to query the RPM database. This is most useful for the long commands with query formats, especially if you have a hard time remembering all the formats. Querying for all packages installed at the same time If you want to list all the packages that were installed with the same transaction ID as a particular package, for example, you can use a script like rpmtran, in Listing 15-4. Listing 15-4: rpmtran #!/bin/sh tid=`rpm -q --qf "%{INSTALLTID}\n" $*` rpm -q --tid $tid This script uses the query format to get the transaction ID, or tid, for a particular package. It then passes this transaction ID to the rpm command to query for all packages installed with the same transaction ID. For example: $ ./rpmtran tcl itcl-3.2-74 tclx-8.3-74 tcl-8.3.3-74 tix-8.2.0b1-74 tkinter-2.2.1-17 Reading HTML documentation for a package You can combine the rpm command with other commands as well. For example, the rpm ???qd command lists the documentation files with a package. If this documentation is in HTML format, you can display this documentation in a Web browser such as Mozilla. Furthermore, by convention, the starting page for HTML documentation should be a file named index.html. Listing 15-5 combines all these factors: Listing 15-5: rpmmoz #!/bin/sh html_file=`rpm -qd $* | grep index.html | head -n 1 ` echo "Launching Web browser with $html_file" htmlview $html_file & This script searches for the documentation for a given package name, finds the first file named index.html, and launches the Web browser in the background to display this file, using the htmlview command which will likely run mozilla or your configured Web browser. When you run this command, you should see output like the following; then the Web browser should appear: $ ./rpmmoz rpm-devel Launching Web browser with /usr/share/doc/rpm-devel-4.1/apidocs/html/index.html Note This script does not check for errors. If there are no files named index.html, the script launches the Web browser anyway. You could fix this by changing the script to validate the html_file variable prior to launching the Web browser. Where to Go From Here This chapter just introduces the basics for shell scripting. There are many more things you can do. The online manual pages for the bash or tcsh commands provide a wealth of reference information on these shells. A number of Web sites provide tutorials on bash, including http://pegasus.rutgers.edu/~elflord/unix/bash-tute.html and www.linuxorbit.com/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=459. In addition, the Linux Documentation Project at www.tldp.org/guides.html provides a bash scripting guide, along with a number of bash- and shell-related how-to documents at www.tldp.org/HOWTO/HOWTO-INDEX/howtos.html. Teach Yourself Linux, by Steve Oualline and Eric Foster-Johnson (John Wiley & Sons, 2000), introduces a number of Linux topics, including text editors and scripting, for those new to Linux. And Graphical Applications with Tcl and Tk (Hungry Minds, Inc., 1997) by Eric Foster-Johnson, covers another scripting language, Tcl/Tk. Use your imagination. Any command that you run often or that is hard to type can be scripted. Furthermore, you can write complex scripts that automate some of the more tedious tasks you need to perform. Summary Scripting is the art of writing a set of commands into text files to speed up your work. Programming is the art of writing a set of commands into text files, compiling the text files, and getting paid more. Choosing when to program and when to script isn???t always a clear-cut decision, but generally programs are move involved and complex, while scripts are shorter tools that automate your work. This chapter provides just a glimpse of all you can do with scripts and the RPM system. Scripts work very well for capturing obscure syntax options for the rpm command, especially the query formats. You can figure out a command once and then save the command as a script to save time in the future. Scripts aren???t the best choice for all tasks, though. In many cases, you need to write a program to accomplish your goals. The next chapter delves into the RPM C programming API, rpmlib. From fedora-docs-commits at redhat.com Tue Oct 4 02:03:58 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 22:03:58 -0400 Subject: rpm-guide rpm-guide-specfile-syntax-en.xml,NONE,1.1 Message-ID: <200510040203.j9423wco002468@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv2455 Added Files: rpm-guide-specfile-syntax-en.xml Log Message: --- NEW FILE rpm-guide-specfile-syntax-en.xml --- Spec File Syntax In This Appendix *The package information tags *Build sections The RPM spec file is divided into two main parts: the package information tags, such as the name of the package, and the build sections, such as the commands to compile the software. The following sections summarize the spec file syntax. Package Information Tags The package information tags contain most of the header tags that you can query with the rpm command. First and foremost, this includes a name. The name-epoch-version-release tags, which form the NEVR used to identify packages, should all appear in your spec file, although you can skip the Epoch tag. Name: name # Epoch: 1 Version: version_number Release: package_release_number The optional Epoch tag provides an ordering for the version numbers (replacing the deprecated Serial tag). Use this tag if RPM cannot figure out the ordering of which release comes after another. Epoch: 42 A number of tags allow you to define who made the package and under what conditions has the package been released: Vendor: name_of_vendor URL: URL_to_package_home Copyright: package_copyright_message Distribution: Linux_or_product_distribution Packager: John Q. Smith <john.smith at somecompany.yow> Group: group_for_categorizing_package Use the Group tag to help users categorize your package. The Icon tag allows you to provide a desktop icon for the package: Icon: filename.xpm A one-line summary is essential to tell users what your package is for: Summary: one_line_description_of_package You should also include a longer description section, marked by %description: %description Tcsh is an enhanced but completely compatible version of csh, the C shell. Tcsh is a command language interpreter which can be used both as an interactive login shell and as a shell script command processor. Tcsh includes a command line editor, programmable word completion, spelling correction, a history mechanism, job control and a C language like syntax. In the description section, blank lines indicate paragraphs. Lines that start with a space are not formatted. Comments To help document your work, you can include comments (to yourself and others reading the spec file). Any line starting with a hash character, #, holds a comment. RPM will ignore comments. # This is a comment. In spec files, comments are used mostly to help explain your syntax choices to yourself should you view the spec file later. Note Avoid percent signs, %, in comments, which may get interpreted as RPM macros. See Chapter 10 for details. Build settings The BuildArchitectures tag names the architectures that a binary RPM will run on. See Chapter 21 for a description of the architecture settings. A special value of noarch indicates a package that is not dependent on a particular architecture, such as a Perl or Python script. The BuildPreReq tag lists any prerequisites for building. For example: BuildPreReq: ncurses-devel The Buildroot tag names the temporary directory in which to build the package. For example: Buildroot: %{_tmppath}/%{name}-root Dependency tags Dependency tags define all the dependencies for the package, as described in Chapter 6. For each dependency, you can specify a capability name alone. For example: Provides: capability_name You can also provide a particular version number or indicate that your package has a dependency on a version larger or smaller than a given number. For example: Requires: capability_name >= version_number Requires: capability_name <= version_number Requires: capability_name > version_number Requires: capability_name < version_number Requires: capability_name == version_number Requires: capability_name = version_number The == and = act the same for dependencies. Both check for a version equal to the given number. You can provide multiple items, separated by commas. For example: Requires: python >= 1.3, perl For add-on modules for interpreters, especially Perl, you can use the following syntax to define capabilities: Provides: perl(MIME-Base64) This example provides the MIME-Base64 add-on Perl module. You can also use or to specify more than one possibility. For example: perl(IO-Wrap) == 4.5 or perl(IO-Wrap)-4.5 The Provides, Requires, Obsoletes, and Conflicts dependency tags all work the same for capability names and version numbers. Note You can also specify BuildRequires tags for capabilities necessary to build the package, not to install it. A BuildConflicts tag names capabilities that conflict for building, such as a particular version of the gcc C compiler. Source files The source and patch tags identify the source files used to build the binary package. The patch tags identify any patches used to modify the sources. If you have more than one of a particular kind of tag, append a number. For example: Source0: ftp://ftp.uk.linux.org/pub/linux/telnet-%{telnet_version}.tar.gz Source2: telnet-client.tar.gz Source3: telnet-xinetd Source4: telnet.wmconfig Patch1: telnet-client-cvs.patch Patch5: telnetd-0.17.diff Patch6: telnet-0.17-env.patch Patch7: telnet-0.17-issue.patch Patch8: telnet-0.17-sa-01-49.patch Patch9: telnet-0.17-env-5x.patch Patch10: telnet-0.17-pek.patch Macros You can define macros in your spec files to help control how the package gets built. The following section describes these macros. Variable definition macros The %define macro allows you to define new macros from within your spec file. A common usage is to define top-level directories with %define macros at the top of a spec file and then reference these directories throughout the file. For example: %define_bindir/bin This allows you to change the setting in one place, which is very handy for directory paths used throughout your spec files. Cross Reference See the section on Defining Macros in Spec Files in Chapter 21 for more on this subject. You can use this syntax for other things that may commonly change, such as version numbers. For example: %define major 2 %define minor 2 %define patchlevel 7 Version: %{major}.%{minor}.%{patchlevel} Table B-1 lists more special macros used within spec files. Table B-1 Special spec file macros Macro Usage %dump Prints out macro values %{echo:message} Prints message to stderr %{error:message} Prints message to stderr and returns BADSPEC %{expand:expression} Like eval, expands expression %{F:file_exp} Expands file_exp to a file name %global name value Defines a global macro %{P:patch_exp} Expands patch_exp to a patch file name %{S:source_exp} Expands source_exp to a source file name %trace Toggles the printing of debugging information %{uncompress:filename} Tests if file filename is compressed. If so, uncompresses and includes in the given context. If not compressed, calls cat to include file in given context. %undefine macro Undefines the given macro %{warn:message} Prints message to stderr Conditional macros You can use a special syntax to test for the existence of macros. For example: %{?macro_to_test: expression} This syntax tells RPM to expand the expression if macro_to_test exists, otherwise ignore. A leading exclamation point, !, tests for the non-existence of a macro: %{!?macro_to_test: expression} In this example, if the macro_to_test macro does not exist, then expand the expression. The %if macro performs an if test much like scripting languages. For example: %if %{old_5x} %define b5x 1 %undefine b6x %endif A %else allows you to specify what to do if the test is not successful. For example: %if %{old_5x} %define b5x 1 %undefine b6x %else %define b6x 1 %undefine b5x %endif Again, use an exclamation point to negate the test. For example: %if ! %{old_5x} %define b5x 1 %undefine b6x %endif You can use a && for an and test. For example: %if %{old_5x} && %{old_6x} %{error: You cannot build for .5x and .6x at the same time} %quit %endif Built-in macros The following macros are built into RPM and can help allow you to place your files in the right locations: %_prefix /usr %_exec_prefix %{_prefix} %_bindir %{_exec_prefix}/bin %_sbindir %{_exec_prefix}/sbin %_libexecdir %{_exec_prefix}/libexec %_datadir %{_prefix}/share %_sysconfdir %{_prefix}/etc %_sharedstatedir %{_prefix}/com %_localstatedir %{_prefix}/var %_libdir %{_exec_prefix}/lib %_includedir %{_prefix}/include %_oldincludedir /usr/include %_infodir %{_prefix}/info %_mandir %{_prefix}/man Build Sections After providing information about the package, you need to define the build stages, as described in Chapters 10 and 12. Build preparation The build preparation section sets the stage for the build. Usually this section has a %setup command. For example: %prep %setup -q Build The build section describes how to build the library or application. In most cases, the majority of the instructions are in the Makefile created by the prep section, leaving a build section something like the following: %build %configure make Installation After building, the installation section holds the commands to install the library or application. For example: %install rm -rf %{buildroot} %makeinstall Clean up The clean up section usually calls the make clean command to clean up the built files. For example: %clean rm -rf %{buildroot} Install and uninstall scripts RPM packages can run scripts prior to installation with %pre, and after installation with %post. You can also run scripts prior to an uninstall with %preun and after an uninstall with %postun. For example: %post /sbin/chkconfig --add ypbind %preun if [ "$1" = 0 ] ; then /sbin/service ypbind stop > /dev/null 2>&1 /sbin/chkconfig --del ypbind fi exit 0 %postun if [ "$1" -ge 1 ]; then /sbin/service ypbind condrestart > /dev/null 2>&1 fi exit 0 File Tags The %files tag lists the files your package should install. For example: %files %defattr(-,root,root) /usr/X11R6/bin/xtoolwait /usr/X11R6/man/man1/xtoolwait.* You should mark configuration and documentation files with %config and %doc, respectively. For example: %files %defattr(-,root,root) /sbin/ypbind %{_mandir}/*/* %config /etc/rc.d/init.d/* %config /etc/yp.conf %dir /var/yp %dir /var/yp/binding %doc README NEWS Making relocatable packages You can make a relocatable package by setting up one or more Prefix tags. For example: Prefix: /usr Prefix: /etc Each file in the %files section must then start with one of the prefixes you provided. With this, installers can easily relocate the package with a command like the following: # rpm --relocate /etc=/usr/etc file_name.rpm The Change Log The change log usually appears at the end of a spec file. It holds messages for each significant change. For example: %changelog * Fri Jun 21 2002 Bob Marley <marley at redhat.com> - automated rebuild * Tue May 08 2001 Peter Tosh <tosh at redhat.com> 1.3-1 - updated to 1.3 From fedora-docs-commits at redhat.com Tue Oct 4 02:05:10 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 22:05:10 -0400 Subject: rpm-guide rpm-guide-transactions-en.xml,NONE,1.1 Message-ID: <200510040205.j9425AQ0002509@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv2488 Added Files: rpm-guide-transactions-en.xml Log Message: --- NEW FILE rpm-guide-transactions-en.xml --- Transactions In This Chapter *Understanding transactions *Querying for packages based on transactions *Rolling back transactions *Saving old packages when upgrading When packages depend on other packages, you may have to install multiple packages to add a single application. Some of the packages may install cleanly; others may not. But you have to install all of the packages to get the complete application. The designers of the RPM system understood this problem and added the concept of transactions to RPM. This chapter covers transactions and how they can help you cleanly install a set of dependent packages. But transactions won???t solve all your problems. You still have to resolve conflicts and dependencies by using the techniques provided in the last three chapters. Understanding Transactions A transaction is a way to delimit a set of operations. All the operations can be undone, often called rolled back. Once rolled back, the system is back in the same state it was prior to the transaction. If all the operations succeed, though, the system will be in a new state. The key issue is that all of the operations must complete successfully, or you can roll back the entire transaction. The assumption is that if any of the operations fail, the system will be in an inconsistent or erroneous state. Transactions are a way to prevent that. Transactions are common when working with databases, but they are just as important when working with packages. Starting with RPM version 4.0.4, transactions and rollbacks became a workable part of any administrator's toolkit. With RPM, the rpm command sets up a transaction any time you attempt to install, remove, or upgrade more than one package. The rpm command automatically makes a transaction. When do you need transactions? Whenever you install or remove packages, the RPM system assigns a transaction and a transaction ID to the set of packages. You can then perform operations on the packages that share the same ID, including rolling back the transaction. Note Rollbacks work only for package upgrades with the 4.1 version of the RPM system, not package installs The RPM system saves an image of the RPM package header for each package installed or removed. You can use this image, along with RPM transaction IDs, to back out of transactions should something go wrong when setting up your system. The main advantage of transactions with RPM, though, is the fact that the rpm command automatically sets up a transaction for all the packages on each command line and does not perform the operation if any package fails. This ability to automatically set up transactions for each call to the rpm command eliminates many errors when working with packages. Use a transaction when you need to be sure that a set of packages install properly. Backing out of transactions With RPM, backing out of a transaction involves two operations: rolling back the transaction and reinstalling the former packages to restore the previous system state. In the simplest case, the rpm command handles all the tasks for you. If you try to install, upgrade, or remove multiple packages and any package fails, the rpm command will restore the system state for you. This automatic support for transactions is a great help to system administrators, but it only applies when you first install, upgrade, or remove the packages. If you have upgraded your system and later discover problems, then you can also use the --rollback option to roll the system back from a set of upgrades, in a limited set of circumstances. Transactions with the rpm Command To set up an RPM transaction, you don't have to do much. All you need to do is pass more than one RPM package on the rpm command line. For example, to set up a transaction for installing three packages, use a command like the following: rpm -ihv package1.rpm package2.rpm package3.rpm If any of the packages fail to install, the rpm command will not install any packages. All of the packages will be installed, or none. This way, if you have a number of packages that together perform some function, such as an Integrated Development Environment (IDE), along with program-language compilers and other software-development tools, you can ensure that all get installed. As an example, say you need to install the gnorpm package, which provides a graphical front end for the rpm command, and the rpmrebuild package, which allows you to create RPMs from already-installed packages. Cross Reference The gnorpm command is covered in Chapter 8. The rpmrebuild package is covered in the "Saving Old Packages" section in this chapter. You can install these packages with a transaction by using the following command: # rpm -ihv gnorpm-0.9-1.i386.rpm rpmrebuild-1.0-0.noarch.rpm Preparing... ########################################### [100%] package gnorpm-0.9-1 is already installed The rpmrebuild package can be installed. (We know this since the rpm command did not issue an error about this package.) But because it was on the same command line as the gnorpm package, the transaction failed. No packages were installed. To check that the rpmrebuild package was not installed (that is, to check that the transaction worked as expected), you can use the rpm ???q command to see if the rpmrebuild package was installed or not. To do so, use a command like the following: # rpm -q rpmrebuild package rpmrebuild is not installed This shows that the rpmrebuild package was not installed, even though the package could be installed on its own. To check that the package could be installed, you can use the --test option, as shown following: # rpm -i --test rpmrebuild-1.0-0.noarch.rpm # This command shows that the rpmrebuild package would install successfully on its own. If there were problems, the rpm command would have issued an error message. This example shows that when you try to install multiple packages with the rpm command, should any fail, the rpm command will not install any. The rpm command works similarly for removing packages and upgrading packages. When removing packages, you???ll see an error like the following if any of the packages on the command line cannot be removed: # rpm -e setup jikes-1.17 error: Failed dependencies: setup is needed by (installed) basesystem-8.0-1 setup >= 2.0.3 is needed by (installed) initscripts-6.95-1 setup >= 2.5.4-1 is needed by (installed) filesystem-2.1.6-5 setup is needed by (installed) xinetd-2.3.7-2 setup is needed by (installed) dump-0.4b28-4 The setup package could not be removed because it had several capabilities needed by other packages. You can check that the jikes package was not removed by using the rpm ???q command, even though it had no failed dependencies: # rpm -q jikes jikes-1.17-1 This package was not removed because it appeared as part of the same command that failed, so none of the operations were performed. When upgrading, you will also see an error message if any of the package upgrades fail. For example: # rpm -Uhv jikes-1.14-1.i386.rpm autoupdate-3.1.5-1.noarch.rpm error: jikes-1.14-1.i386.rpm cannot be installed You can then check that the jikes package, in this example, was not downgraded to the earlier version with the rpm ???q command: # rpm -q jikes jikes-1.17-1 Transaction IDs The rpm command gives every package installed a transaction ID. The transaction ID is a Unix time stamp (number of seconds since January 1, 1970). You can then perform some operations on packages based on the transaction ID. Note The fact that a transaction ID uses a Unix timestamp may change in the future. All the packages installed at the same time are given the same transaction ID. This means that you can perform operations on a set of packages, the packages that were installed together. But there???s also a downside to this. All the packages installed when you first installed or upgraded your Linux system are given the same transaction ID. This means you cannot selectively act on these packages using the transaction ID, because you will likely get far more packages than you want to work on. Viewing RPM Transaction IDs To view the install transaction ID (a date code) for a given package, you can use a command like the following: $ rpm -q --qf "%-20{NAME} %-20{INSTALLTID}\n" jikes jikes 1035589778 This command uses the --qf or --queryformat option to specify the data to return from the RPM query command. In this case, the command requests the name of the package as well as the transaction ID (TID) for installation. Cross Reference Chapter 5 describes the --queryformat option. There is also a transaction ID for removal, the REMOVETID. You can also query for this ID. For example, if a package hasn't been removed, you'll see an entry like the following: $ rpm -qa --qf "%-20{NAME} %-20{REMOVETID}\n" termcap termcap (none) Viewing the Packages Associated with a Transaction ID Once you have a transaction ID, you can use the --tid option, short for transaction ID, to query for the package associated with a given transaction, using a command like the following: $ rpm -q --tid 1035589778 jikes-1.17-1 This example uses the transaction ID that the earlier query example returned. If you installed more than one package at the same time, you will see a listing of all the packages that share the transaction ID. For example, to see many packages with one transaction ID, you can query for packages installed when you installed or upgraded your version of Linux. First, query for the transaction ID of a package you know was installed with the Linux distribution, such as setup on a Red Hat system: $ rpm -q --qf "%-20{NAME} %-20{INSTALLTID}\n" setup setup 1033838323 Second, use this transaction ID and query for all packages with this ID, using code like the following: $ rpm -q --tid 1033838323 | more redhat-menus-0.26-1 glibc-2.2.93-5 cracklib-2.7-18 gdbm-1.8.0-18 gmp-4.1-4 libacl-2.0.11-2 libjpeg-6b-21 linc-0.5.2-2 pcre-3.9-5 shadow-utils-20000902-12 libtermcap-2.0.8-31 freetype-2.1.2-7 info-4.2-5 fileutils-4.1.9-11 psmisc-20.2-6 ntp-4.1.1a-9 mount-2.11r-10 cracklib-dicts-2.7-18 krb5-libs-1.2.5-6 cyrus-sasl-2.1.7-2 usermode-1.63-1 Xft-2.0-1 Note Be sure to replace the transaction ID shown here with the transaction ID obtained by querying your system. This example shows just a few of the packages installed when the Red Hat Linux was installed. With these options, you can find the transaction IDs for given packages and can use the rpm command to install, remove, or otherwise modify the packages that share a transaction ID. Rolling Back Transactions The --rollback option to the rpm command allows you to roll back upgrades based on a time. Use a command like the following: # rpm ???U --rollback "3 months ago" The --rollback option is very limited in what it can do. The --rollback option works only for packages that have been upgraded. You cannot rollback the initial installation of a package. This is to prevent you from accidentally rolling back all packages. The --rollback option works best if you want to restore the system to a previous state, prior to performing any other RPM operations. That is, soon after you upgraded a package and decide that it isn???t working right. If you have modified the RPM system after performing the transaction you want to rollback, there may be unintended consequences if any new package depends on the packages you want to roll back. In addition, the --rollback option only works in limited situations but does not always report when these conditions are not met. The rpm command may simply do nothing, or it may remove packages you do not expect. Warning Before running the --rollback option, backup your RPM database as described in Chapter 5. Because of all these limitations, rollbacks do not work in all situations. In place of the --rollback option, you can use the query shortcuts introduced in Chapter 5 and find the packages you have installed recently (if that is what you want to roll back). In this case, you can use the rpm command to remove the packages you want to get rid of and reinstall the packages you want to restore. In many cases, this manual approach is safest, and you will have a clearer understanding about what was installed or upgraded on your system. Saving Old Packages When installing, removing, or upgrading, you can use the --repackage command-line option to save a version of something like the old package to a file, making a backup of the older package contents. Warning The package created by the --repackage option is not a complete RPM package. You can use the rpmbuild command to make it into a complete package, but by itself, it will not be a complete package. See Chapters 10, 11, and 12 for more on building packages. You can later reinstall the old files, once they have been made into a complete package. This can be quite useful if something goes wrong or the upgraded package has bugs. You can fall back to the old package if needed. By default, the --repackage option puts the old package in the /var/spool/repackage directory. Other common directories are /var/spool/up2date or /var/tmp. Your RPM configuration determines the directory used by this option. Note The up2date name comes from the Red Hat service for keeping a system up to date with regard to package versions. For example, say you have a package, jikes (a Java programming language compiler used in previous examples) that you want to upgrade. But you are worried that the new version may not work properly. First, check the version you have. For example: # rpm -q jikes jikes-1.14-1 This shows you are at version 1.14 of the jikes Java compiler. You can then upgrade to version 1.17 while repackaging the old version, as shown following: # rpm -Uhv --repackage jikes-1.17-glibc2.2-1.i386.rpm Preparing... ########################################### [100%] Repackaging... 1:jikes ########################################### [100%] Upgrading... 1:jikes ########################################### [100%] This upgrade has kept a copy of the old package in the /var/spool/repackage directory. You can verify this with the following command: $ ls -l /var/spool/repackage/ total 692 -rw-r--r-- 1 root root 703037 Oct 25 18:49 jikes-1.14-1.i386.rpm You can see a version of the old package, with the old version number. Warning This is not the same as the original package. This is not a complete package. The repackaged RPM contains a snapshot of the package???s files as they were on your hard disk, not as they were when you originally installed the package. Thus, the contents may differ if the files have changed on your hard disk. In addition, the --repackage option may not properly sign the package as the original was. In addition to the --repackage option with the rpm command, you can use a free tool called rpmrebuild to make snapshots of any installed packages. Written by Eric Gerbier, rpmrebuild allows you to create an RPM from the installed, and perhaps modified, version of a package. You don???t have to upgrade, remove, or install a new package, as you do with the --repackage option. Download rpmrebuild from http://rpmrebuild.sourceforge.net/. Summary Transactions allow you to install multiple packages as a group and know that either all the packages will succeed in installing or none of them will. This is very important if you have a set of interlocking packages that you need to install. All the packages you install, remove, or upgrade on the same command line are automatically made part of a transaction. The rpm command will ensure that all packages can be installed, removed, or upgraded, and will not perform the operation unless all will succeed. All packages installed or removed are given a transaction ID, which uses a Unix timestamp (the number of seconds since January 1, 1970). All packages installed or removed at the same time are given the same transaction ID. You can then query by transaction IDs to perform operations on all the packages installed together. The --repackage option tells the rpm command to make a backup RPM of the current package when you are installing or upgrading a more recent version or removing the package. By default, the backup RPM is placed in the /var/spool/repackage directory. Note that a package created this way is not exactly the same as the original package. Files may have changed on disk. In addition, packages created with the --repackage option are not real valid RPM packages. You cannot install these packages without performing extra operations to create a real RPM package from the repackaged data. From fedora-docs-commits at redhat.com Tue Oct 4 02:07:28 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 22:07:28 -0400 Subject: rpm-guide rpm-guide-using-rpm-db-en.xml,NONE,1.1 Message-ID: <200510040207.j9427S4u002561@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv2533 Added Files: rpm-guide-using-rpm-db-en.xml Log Message: --- NEW FILE rpm-guide-using-rpm-db-en.xml --- Using the RPM Database In This Chapter *Querying the RPM database *Getting information on RPM files * Finding out which packages own files on your system * Verifying installed packages *Backing up the RPM database *Repairing damaged RPM databases Every package you install with RPM is recorded in the RPM database. The RPM system includes commands to query this database to find out which packages are installed and to provide quite a few details about these packages. This chapter covers querying both the RPM database and RPM package files. Both types of query are important: *Query the RPM database to see what is installed, or not installed, on your system. *Query package files to see what the files require, as well as what the files provide. In addition to querying the RPM database, you can use the database to verify packages. Since this database is so important to the management of your Linux system, this chapter covers how to back it up, as well as how to repair a damaged RPM database. Querying the RPM Database In Chapter 4, you saw that the rpm command usually takes one major command-line option to tell it the operation to perform and a myriad of command-line options to customize the operation. The rpm command may also take the name of one or more RPM package files or the name of one or more installed packages. For example, the rpm ???i command performs an installation operation, and the rpm ???U command performs an upgrade. For querying the RPM database, the major command-line option is ???q, short for query. This option tells the rpm command to query the RPM database. You can also use the long option --query. In the last few chapters, you've used the ???q option with the rpm command to query just for the presence or absence of installed packages. You can expand the -q option to perform a wide array of queries to find out information about the packages installed on a Linux system. Querying packages The basic format of the rpm ???q command follows: rpm ???q package_name You need to provide the name of a package to query. For example: rpm -q telnet-0.17 This command returns the name of the package, if installed. For example: telnet-0.17-20 If the package is not installed, you???ll see a message like the following: package telnet-0.17 is not installed You can provide the whole package name to the rpm command, which includes the name, the version, and the RPM package number, as discussed in Chapter 3. You can also just provide the name and version number, as shown previously, or just the base name of the package. For example, the following command uses just the base name of the package: $ rpm -q telnet telnet-0.17-20 Note The rpm ???q command expects a package name. Although it supports some amount of customized queries, you really need to know which packages you want the rpm command to report on. You can provide more than one package name; the rpm command reports on each package, as shown following. $ rpm -q telnet telnet-server telnet-0.17-20 telnet-server-0.17-20 You need to change the way you query if you want to perform searches when you do not know the full package name in advance. The following sections cover options for creating various queries. Querying everything Up to now, we have used the rpm command to query only for specific packages. The ???a option tells the rpm command to query for all packages. You can also use the longer option, --all, in place of ???a. For example: rpm -qa This command returns every package installed on your system, quite a few packages. The packages are returned one per line, as shown following. words-2-17 kudzu-0.99.23-1 openldap-2.0.11-13 rpm-4.0.3-1.03 kernel-smp-2.4.7-10 quota-3.01pre9-3 expat-1.95.1-7 [...4111 lines suppressed...] Available from SleepyCat Software at www.sleepycat.com/, the Berkeley DB library provides a simple database API. This is not a traditional relational database. Instead, data values are stored in what amounts to a persistent hash table of name/value pairs. This type of database is very quick to look up a named entry (such as a package name) but is not so quick for iterating over all the entries. One of the nice things about this library is that it is available in an open-source format, and you can get programming API libraries for C, C++, Java, Python, Perl, and Tcl languages. The RPM database is really a number of Berkeley DB databases, each designed for a different type of query. If something goes wrong with your RPM database, you can first try to rebuild it. If that fails, you may need to initialize a new database, although that is generally not needed. First and foremost, however, you should back up this database. Backing up the RPM database As mentioned before, the RPM database resides in the /var/lib/rpm. You can back up the RPM database by using commands such as the following: # cd /var/lib # tar cvf rpmdb.tar ./rpm # gzip rpmdb.tar These commands create a tar archive from the contents of the rpm directory (where the RPM database is stored) and compress the file with the gzip command. Note Adding the z option to the tar command can create a compressed archive directly, without the need for the gzip command. Rebuilding the RPM database If the RPM database has been corrupted in some way, you can use the --rebuilddb option to tell the rpm command to rebuild your database. For example: rpm --rebuilddb This command rebuilds the RPM database from the installed packages, the file named Packages in the /var/lib/rpm directory. Only the Packages file is required. All the other files can be recreated from the Packages file. If your database is OK, this command won't do much, other than shrink the size of your RPM database by removing unused entries. This command will take some time to execute, though. Warning Before running this command, back up your RPM database. To check that the rpm --rebuilddb command has not damaged the RPM database, you can check with a file listing, query all packages, and then check the results of the rpm ???rebuilddb command with another file listing when done. Another useful technique that can help with a corrupted RPM database is to use the db_dump and db_load utilities that come with RPM (from the SleepyCat DB database library). Use db_dump to dump the Packages file. Then, use db_load to reload the Packages file. The act of dumping and restoring may fix a corrupted file. As always, back up your RPM database prior to performing these commands. Creating a new RPM database If all else fails, use the --initdb option to tell the rpm command to create a new empty RPM database. In almost all cases, you do not want to create a new RPM database, since this database will be empty. It will not have any knowledge about the packages you have already installed on your system. That could lead to a lot of problems, since you have the files installed, but the RPM system just doesn???t know about them. The basic syntax follows. rpm --initdb Note This command should not damage an existing database. If the RPM system cannot be rebuilt, you may have to reinstall the operating system to recreate a clean system. In general, if things are this far gone, reinstalling may be your best answer instead of wiping the RPM database and creating an empty database. You can also use the --dbpath option to tell the rpm command to create an RPM database in a different directory. For example: mkdir /tmp/rpm rpm --initdb --dbpath /tmp/rpm These commands create a temporary directory and an RPM database in the /tmp/rpm directory. After running this command, you can examine the files created. # ls -l /tmp/rpm total 288 -rw-r--r-- 1 root root 8192 Oct 10 20:29 __db.001 -rw-r--r-- 1 root root 1310720 Oct 10 20:29 __db.002 -rw-r--r-- 1 root root 360448 Oct 10 20:29 __db.003 -rw-r--r-- 1 root root 12288 Oct 10 20:29 Packages This shows an empty RPM database. Summary This chapter covers the rpm command options to query the RPM database and RPM package files. You can determine the packages installed on your system, as well as which packages are responsible for the files on your system. The RPM database maintains a lot of information about the files and packages on your system. Thus, it is crucial for managing your Linux systems. You should back up the RPM database before and after any installation, upgrade, or removal of packages. You can also use the --rebuilddb option to the rpm command to rebuild a damaged RPM database. From fedora-docs-commits at redhat.com Tue Oct 4 02:09:19 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 22:09:19 -0400 Subject: rpm-guide rpm-guide-using-rpm-en.xml,NONE,1.1 Message-ID: <200510040209.j9429JLJ002592@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv2579 Added Files: rpm-guide-using-rpm-en.xml Log Message: --- NEW FILE rpm-guide-using-rpm-en.xml --- Using RPM Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Chapter *Installing and upgrading software *Removing software This chapter covers the most common uses for RPM: installing, removing, and upgrading software. These are the most frequently used RPM commands. The RPM system includes the options you might expect, such as installing a package, but there???s a lot more you can do. For example, you can install packages from remote sites using HTTP or FTP to download the package to install. There are quite a few other rpm options you can use to get information and feedback on installation, for example. The rpm Command Just about everything you do with RPM requires the rpm command. As a nice added benefit, just about everything you do with RPM requires a single invocation of the rpm command. That means common tasks such as installing and removing software can be done quickly and efficiently. The basics of the rpm command are not very hard, and you can perform the basic tasks within a few minutes of reading this chapter. Upgrading and Installing Software To install software, you need something to install. Typically, this is a file packaged as RPM, using a file-name extension of .rpm. Of course, this isn???t required, but just about every RPM package is stored in a file with a .rpm extension. For example, the following file holds an RPM package, ready to be installed: jikes-1.16-1.i386.rpm This package holds an application named jikes (a Java language compiler application). From the discussion in the last two chapters, you should be able to determine the version of the program this RPM holds and which release of the RPM package this represents. Other RPMs hold sources, the program source codes used to create an application or programming library. For example, the following file holds a source RPM: jikes-1.16-1.src.rpm The src in the package name is short for source. This file-naming convention is not required, but is used by just about all source code packages. (Following conventions helps other administrators know what to expect.) Cross Reference Chapters 9 and 12 cover building RPMs from source RPMs. The rpm command provides three main operations for upgrading and installing packages: An upgrade operation means installing a new version of a package and removing all previous versions of the same package. If you have not installed a package previously, the upgrade operation will install the package. A freshen operation means to install a new version of a package only if you have already installed another version of the package. An install operation installs a package for the first time. It also, through special command-line parameters, allows you to install multiple versions of a package, usually not what you want. So, in the vast majority of cases, you want to run the upgrade operation for all package installations. The following sections cover the command-line options that apply to these operations. Upgrading with the rpm command Almost all installation steps use the rpm command with the ???U option, short for upgrade, as introduced in Chapter 3. The basic syntax is: rpm -U package_name For example: rpm ???i jikes-1.16-1.i386.rpm You can also use the --upgrade long option in place of -U. Unless something goes wrong, you won???t see any response except for the shell prompt ready for your next command. Options for the rpm command, covered shortly, present positive feedback that the package has been installed. The rpm command may print out warnings, such as the one following: warning: pyxf86config-0.3.1-2.i386.rpm: Header V3 DSA signature: NOKEY, key ID 897da07a This warning comes from the fact that the package was signed, but the key was not found. Chapter 12 covers signing packages. In most cases, warnings such as this one are not that serious. Errors, though, should be treated seriously. Note Just about every package you want to upgrade or install requires root, or super user, permissions. That???s because most Linux application RPMs hold files that must be installed in a protected directory such as /usr/bin. In addition, RPM requires root access to modify the RPM database. Even if you could modify the system directories like /usr/bin, you must also be able to modify the RPM database to successfully install or remove packages. Checking That the Package Is Installed Use the rpm ???q command to quickly verify a package has been installed. To verify, you need to use the name of the installed package, not the name of the RPM file. You can also use a partial package name, such as jikes in this case. For example: rpm ???q jikes When you run this command, you should see a response like the following: jikes-1.16-1 The response shows that the package named jikes-1.16-1 has been installed. This package name corresponds to the RPM file used in the preceding installation example. The rpm -q command just asks the RPM database if the package [...1758 lines suppressed...] In most cases, the application looks in the user home directory for a specific file tied to the application. For the rpm command, this file is .rpmrc. The leading period makes the file hidden for most directory listings. In addition to the user-level file of commands, most applications supporting this mechanism have a way for site administrators to customize the command for all users. For example, your system may have a file named /etc/rpmrc (with no leading period) that customizes the rpm command for all users on your system. See page 427 for a more in-depth look at the chain of these files. The syntax for the --rcfile option is --rcfile filename You can also supply more than one file name. This syntax follows: --rcfile filename1:filename2:filename3 Separate each file name with a colon. With Red Hat Linux, the default set of initialization files are: /usr/lib/rpm/rpmrc:/usr/lib/rpm/redhat/rpmrc:/etc/rpmrc:~/.rpmrc Note The ~/.rpmrc means to look in the user's home directory for a file named .rpmrc. You can use the --showrc option to list all the rc settings. Cross Reference See Chapter 21 for more on the --showrc option. The --version option tells the rpm command to print out the version number of the command and then exit. For example: rpm --version This command prints out a version number, like the following: RPM version 4.1 The --dbpath option, mentioned previously, tells the rpm command to use a different RPM database. This is useful when testing a complete system install, where you want to change the RPM database but don't want that to affect your running Linux system. In this case, you can use a different RPM database and test out your changes. The basic syntax for this option is: --dbpath directory_name The --pipe option tells the rpm command to send, or pipe, its output to another program. The syntax for this option is: --pipe command_to_send_out_to Summary This chapter covered the easy part of managing packages, the common actions of installing, removing, and upgrading software. The rpm ???e command removes packages. The rpm ???U command upgrades packages by installing new packages and removing old versions of all the packages upgraded. RPM upgrades also work for installing new packages. The rpm ???F command freshens packages. This command only upgrades a package if an older version of the package has already been installed. The rpm ???i command installs packages. Table 4-3 summarizes the rpm command-line options for installing, removing, and upgrading packages. Table 4-3 Installing, Removing, and Upgrading with the rpm command Command Usage rpm ???i install_options package_files Install packages. rpm ???e remove_options packages Erase, remove, packages. rpm ???U install_options package_files Upgrade or install packages. Use this option for installations. rpm ???Uvh install_options package_files Upgrade or install packages with extra output. This is the recommended command to install packages. rpm ???F install_options package_files Freshen packages. Unfortunately, modern system management gets more complex than that. The next chapter delves into package dependencies and the nightmare you can get into when one package depends on another that then depends on another, ad infinitum. From fedora-docs-commits at redhat.com Tue Oct 4 02:15:59 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 3 Oct 2005 22:15:59 -0400 Subject: rpm-guide rpm-guide-specfiles-en.xml,NONE,1.1 Message-ID: <200510040215.j942Fx8B002654@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv2636 Added Files: rpm-guide-specfiles-en.xml Log Message: --- NEW FILE rpm-guide-specfiles-en.xml --- Working with Spec Files Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). In This Chapter *Writing spec files *Defining package information *Controlling the build *Listing the files in the package *Defining spec file macros The previous chapter introduces the concepts of how to build RPMs, and briefly covered the spec file, which controls how RPM packages are built and installed. This chapter delves into how to create spec files and the next chapter covers advanced spec file topics such as using conditional commands and making relocatable packages. A spec file defines all the commands and values that are required for creating a package, everything from the name and version number to the actual commands used to build the program you are packaging. This chapter covers the spec file syntax and how to write spec files. In goes in depth into defining information about your package, controlling how the software will be built, defining what exactly should go into the package, and customizing your build with RPM macros. Reading Spec Files The first step to learning more about spec files is to read through some of the huge number of spec files for the source RPMs that come with your Linux distribution. Looking at these files will show two things right away: *You will see that the spec file syntax is not really as complicated as it appears. *You will see how many others have solved problems similar to those you need to solve. I???ve used real-world examples throughout this book, to show how the RPMs you need to deal with actually work. Some of the more interesting packages include anything that has a client and a server component, anything with networking or e-mail, and anything that installs a system service. All these types of packages solve problems that you will commonly face. Some useful spec files to look at are those for anonftp, telnet, vnc, and sendmail. To get these spec files, you need to install the corresponding source RPMs for each of these packages. As you read through spec files, you???ll start to see common patterns in how packages are defined, named, the macros used, and common elements in the build sections of the spec files. You???ll also see how network services are installed on Linux, as well as example install and uninstall scripts. The next sections provide more information on the things to look for within spec files. Furthermore, even with the plethora of options RPM provides, if you know shell scripting basics and something about how C programs are normally built, with configure scripts and make commands, you will find most spec files relatively easy to understand. The following sections go into the details of writing your own spec files. Keep your example spec files handy as you read through these sections. Writing Spec Files Spec files are text files containing RPM directives. These directives use a simple syntax of a tag name, a colon, and a value: TagName: value For example: Version: 1.15 This example sets the package version to 1.15. The name of the item is not case sensitive, so tag names of version, Version, or VERSION all set the same value. This syntax works for most settings, including Name, Release, and so on. In addition to this directive syntax, you can define macros using the RPM %define syntax. For example: %define major 2 This example defines a macro named major with a value of 2. Once defined, you can access macros using the %{macro_name} or just %macro_name syntaxes. For example: source: %{name}-%{version}.tar.gz See the section "Defining Spec File Macros" later in this chapter for more options for macros. Major sections in the spec file are also delimited with % markers. For example, the build section starts with %build on a line by itself. Note The multiple uses of the % sign aren???t really that confusing in practice. Read through some spec files and you should find most of the commands are easily understood. Blank lines separate sections in the spec file, which makes sense for readability as well. Comments To help document your work, you can include comments (to yourself and others reading the spec file). Any line starting with a hash character, #, holds a comment. RPM will ignore comments. # This is a comment. In spec files, comments are mostly to help explain your syntax choices to yourself should you view the spec file later. Comments are a good thing. You should comment heavily, especially for any choice that deviates from the norm. For example, if you provide special C compiler options for building the package, add comments to describe why you picked the options and how necessary they are. Such comments help immensely should you need to port the RPM to another architecture or modify how it was built. Tip Avoid single percent signs, %, in comments. For example: # Added new commands to %prep The rpmbuild command may report an error of a second %prep section. To get around this problem, use two percent signs, such [...2526 lines suppressed...] <require name="make" /> </buildrequires> <!-- packages --> <package group="System/Base" autoreqprov="no"> <requires> <require name="glibc" /> </requires> <summary>The Bash package contains the bash program.</summary> <description>%{summary} Bash is the Bourne-Again SHell, which is a widely used command interpreter on Unix systems. Bash is a program that reads from standard input, the keyboard. A user types something and the program will evaluate what he has typed and do something with it, like running a program.</description> <files list="%{name}.files.lst" /> </package> <package name="bash-doc" group="Documentation/System/Base" autoreqprov="no"> <requires> <require name="%{name}" /> </requires> <summary>Documentation for the bash package.</summary> <description>%{summary}</description> <pre script="%{name}-doc.pre.sh" /> <files list="%{name}-doc.files.lst" /> </package> <!-- scripts to create the package --> <prep script="%{name}.prep.sh"> <setup /> <script>echo &quot;Prep completed&quot;</script> </prep> <build script="%{name}.build.sh" /> <install script="%{name}.install.sh" /> <clean script="%{name}.clean.sh" /> <!-- changelog --> <changelog> <changes date="Mon Aug 26 2002" version="2.05a-02test" author="" author-email=""> <change>Added setup macro to extract files</change> <change>Initial version ready for jbj</change> </changes> </changelog> </spec> Note XML spec files are a very experimental feature. Future releases of RPM will likely provide more support for XML spec files. The format will likely change. Summary This chapter covers spec files, the files that define how to build packages. Start your spec file by defining package information, such as the name, version, and release number. You can also add a detailed description to help administrators decide whether to install your packages. You need to name all of the source and patch files used to build the package. In most cases, the source files are compressed tar archives. After naming all the sources and patches, you need to control how the rpmbuild command should build your package. This comes in four sections. The %prep section prepares for the build by extracting the source files and applying patches. The %build section defines the commands to build the software, normally something as simple as running a configure script and then the make command. The %install section contains the commands for installing the software. And, the %clean section provides commands to clean up after the build. For these sections, you can use handy RPM macros for common tasks, such as running the configure script or the make install command. You can also define scripts the rpm command should run before and after installing, as well as before and after removing the package. Spec files contain a listing of all the files that should go into the package, as well as where those files should be placed on the user???s hard disk. You can define RPM macros in your spec files to make commands that can work with different directory structures as well as simplify common commands. While it may seem that this chapter described a great many options for making spec files, there???s more to come. The next chapter covers advanced spec file topics such as triggers, conditional builds, and specifying dependencies. From fedora-docs-commits at redhat.com Wed Oct 5 12:00:48 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Wed, 5 Oct 2005 08:00:48 -0400 Subject: jargon-buster jargon-buster-en.xml,1.10,1.11 Message-ID: <200510051200.j95C0mvJ025335@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/jargon-buster In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv25312 Modified Files: jargon-buster-en.xml Log Message: Pushed to 1.9.4, made several corrections (#160265) Index: jargon-buster-en.xml =================================================================== RCS file: /cvs/docs/jargon-buster/jargon-buster-en.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- jargon-buster-en.xml 7 Sep 2005 22:20:46 -0000 1.10 +++ jargon-buster-en.xml 5 Oct 2005 12:00:46 -0000 1.11 @@ -4,7 +4,7 @@ %FEDORA-ENTITIES-EN; - + ]> @@ -180,6 +180,16 @@ + + 1.9.4 + 30 Sep 2005 + PaulWFrields + + + Some term fixes (#160265). + + + @@ -274,8 +284,8 @@ Use BitTorrent to download &FC; by downloading and opening a torrent file. The official &FC; torrent tracker is located at . Download a torrent - file there to begin downloading a release of &FC;. + url="http://torrent.fedoraproject.org/"/>. Download a + torrent file there to begin downloading a release of &FC;. @@ -988,20 +998,6 @@ - - redhat-config-packages - - - The redhat-config-packages - utility is a package installation for new &FC; systems which - have no software updates installed yet. Since most - administrators and users update their system software - regularly, redhat-config-packages - is not often used. Users should instead use the utility to install new software. - - - rhgb @@ -1103,6 +1099,20 @@ RPM + + system-config-packages + + + The system-config-packages + utility is a package installation for new &FC; systems which + have no software updates installed yet. Since most + administrators and users update their system software + regularly, system-config-packages + is not often used. Users should instead use the utility to install new software. + + + up2date From fedora-docs-commits at redhat.com Tue Oct 11 22:23:39 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Tue, 11 Oct 2005 18:23:39 -0400 Subject: docs-common/bin xmlformat-fdp.conf,1.5,1.6 Message-ID: <200510112223.j9BMNdRL006978@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/docs-common/bin In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv6956 Modified Files: xmlformat-fdp.conf Log Message: Add simpara to overall normalization group Index: xmlformat-fdp.conf =================================================================== RCS file: /cvs/docs/docs-common/bin/xmlformat-fdp.conf,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- xmlformat-fdp.conf 20 Aug 2005 21:35:21 -0000 1.5 +++ xmlformat-fdp.conf 11 Oct 2005 22:23:36 -0000 1.6 @@ -48,7 +48,7 @@ normalize = yes # "Normalize" means make smart whitespace decisions -para example important note warning caution itemizedlist variablelist varlistentry +para simpara example important note warning caution itemizedlist variablelist varlistentry normalize = yes title titleabbrev From fedora-docs-commits at redhat.com Tue Oct 11 23:43:04 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Tue, 11 Oct 2005 19:43:04 -0400 Subject: example-tutorial Makefile,1.14,1.15 Message-ID: <200510112343.j9BNh4lQ010255@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/example-tutorial In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv10210 Modified Files: Makefile Log Message: Reduce rpmbuild verbosity Index: Makefile =================================================================== RCS file: /cvs/docs/example-tutorial/Makefile,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- Makefile 3 Oct 2005 02:46:04 -0000 1.14 +++ Makefile 11 Oct 2005 23:43:01 -0000 1.15 @@ -40,7 +40,7 @@ DOCOMF=$(PWD)/SOURCES/fedora-doc-$(DOCBASE)-C.omf DOCDESKTOP=$(PWD)/SOURCES/fedora-doc-$(DOCBASE).desktop DOCSRCTAR=$(PWD)/SOURCES/$(DOCBASE)-$(VERSION).src.tar.gz -TITLE=$(shell ../docs-common/packaging/titlegrab.py $(DOCBASE)-en.xml) +TITLE=$(shell ../docs-common/packaging/titlegrab.py $(DOCBASE)-en.xml | sed 's/^ \+//') ###################################################### # Some RPM flags... ###################################################### @@ -88,7 +88,7 @@ # # Do the build... # - rpmbuild -bb -vv $(RPMFLAGS) $(DOCSPEC) + rpmbuild -bb $(RPMFLAGS) $(DOCSPEC) mv RPMS/noarch/*.rpm . rpmbuild --clean --rmsource $(RPMFLAGS) $(DOCSPEC) rm -rf {BUILD,RPMS,SOURCES,SPECS,SRPMS} From fedora-docs-commits at redhat.com Wed Oct 12 00:09:43 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Tue, 11 Oct 2005 20:09:43 -0400 Subject: docs-common Makefile,NONE,1.1 Message-ID: <200510120009.j9C09hXe012266@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/docs-common In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv12224 Added Files: Makefile Log Message: Add packaging necessities for fedora-doc-common --- NEW FILE Makefile --- ############################################################################### # Makefile for fedora-doc-common packaging # Created by: Paul W. Frields # License: GPL # Copyright 2005 Paul W. Frields ############################################################################### DOCBASE = fedora-doc-common ###################################################### # Some packaging specific vars VERSION = 0.1 RELEASE = cvs$(shell date +"%Y%m%d") DATE = $(shell date +"%Y-%m-%d") NOW = $(shell date +"%a %b %e %Y") SPECIN = ../docs-common/packaging/$(DOCBASE).spec DOCSPEC = $(PWD)/SPECS/$(DOCBASE).spec DOCSRCTAR = $(PWD)/SOURCES/$(DOCBASE)-$(RELEASE).src.tar.gz TITLE = Fedora Documentation Project Shared Files ###################################################### # Some RPM flags... ###################################################### RPMFLAGS = --define "docbase $(DOCBASE)" \ --define "version $(VERSION)" \ --define "release $(RELEASE)" \ --define "_topdir $(PWD)" ###################################################### clean: rm -rf $(DOCBASE)*.rpm update: clean cvs update rpm: update # # Make RPM-compliant tarball of source XML and other stuff mkdir $(DOCBASE)-$(RELEASE) find . -maxdepth 1 -type d \( \ -name 'common' -o \ -name 'css' -o \ -name 'stylesheet-images' \) | xargs -i \ find {} -maxdepth 1 -type f ! \( \ -name '.*' -o -name '*~' -o \ -name '*.svg' -o -name '*.eps' \) | \ cpio -pamdv $(DOCBASE)-$(RELEASE) # # Make RPM build tree; don't rely on local user's setup mkdir -p {BUILD,RPMS/noarch,SOURCES,SPECS,SRPMS} tar -zcvf $(DOCSRCTAR) $(DOCBASE)-$(RELEASE) cp $(SPECIN) $(DOCSPEC) rm -rf $(DOCBASE)-$(RELEASE)/ # # Make rpmlint happy with a changelog entry # FIXME: Maybe more magic would make this stickier; pity # I'm no magician... sed 's/\(%changelog\)/\1\n* $(NOW) Fedora Docs Project - $(VERSION)-$(RELEASE)\n- Update to $(RELEASE)\n/' \ $(SPECIN) > $(DOCSPEC) # # Do the build... # rpmbuild -bb $(RPMFLAGS) $(DOCSPEC) mv RPMS/noarch/*.rpm . rpmbuild --clean --rmsource $(RPMFLAGS) $(DOCSPEC) rm -rf {BUILD,RPMS,SOURCES,SPECS,SRPMS} From fedora-docs-commits at redhat.com Wed Oct 12 00:09:43 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Tue, 11 Oct 2005 20:09:43 -0400 Subject: docs-common/packaging fedora-doc-common.spec,NONE,1.1 Message-ID: <200510120009.j9C09hAZ012271@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/docs-common/packaging In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv12224/packaging Added Files: fedora-doc-common.spec Log Message: Add packaging necessities for fedora-doc-common --- NEW FILE fedora-doc-common.spec --- # This spec file is only for building supporting common files from the # docs-common module. It is not for use with other docs modules at # this time. Summary: Fedora Documentation common files Name: fedora-doc-common # To be defined in Makefile Version: %version Release: %release License: FDL Url: http://fedora.redhat.com/projects/docs/ Source0: fedora-doc-common-%release.src.tar.gz Group: Documentation BuildArch: noarch BuildRoot: %{_tmppath}/%{name}-%{version}-root %description This package contains the common entities and XML fragments for official Fedora Documentation. %prep %setup -q -n %{name}-%{release} %build %install rm -rf $RPM_BUILD_ROOT install -d -m 755 $RPM_BUILD_ROOT/%{_datadir}/fedora/doc/docs-common/common/ install -m 644 $RPM_BUILD_DIR/%{name}-%{release}/common/*.{xml,ent} \ $RPM_BUILD_ROOT/%{_datadir}/fedora/doc/docs-common/common/ install -d -m 755 $RPM_BUILD_ROOT/%{_datadir}/fedora/doc/docs-common/css/ install -m 644 $RPM_BUILD_DIR/%{name}-%{release}/css/* \ $RPM_BUILD_ROOT/%{_datadir}/fedora/doc/docs-common/css/ install -d -m 755 $RPM_BUILD_ROOT/%{_datadir}/fedora/doc/docs-common/stylesheet-images/ install -m 644 $RPM_BUILD_DIR/%{name}-%{release}/stylesheet-images/* \ $RPM_BUILD_ROOT/%{_datadir}/fedora/doc/docs-common/stylesheet-images/ %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-, root, root,-) %docdir %{_datadir}/fedora/doc/docs-common/common/ %{_datadir}/fedora/doc/docs-common/common/* %{_datadir}/fedora/doc/docs-common/css/* %{_datadir}/fedora/doc/docs-common/stylesheet-images/* %changelog From fedora-docs-commits at redhat.com Wed Oct 12 14:59:51 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Wed, 12 Oct 2005 10:59:51 -0400 Subject: docs-common Makefile,1.1,1.2 Message-ID: <200510121459.j9CExpCP026343@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/docs-common In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv26305 Modified Files: Makefile Log Message: Fix packaging to properly add menu and desktop files Index: Makefile =================================================================== RCS file: /cvs/docs/docs-common/Makefile,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Makefile 12 Oct 2005 00:09:37 -0000 1.1 +++ Makefile 12 Oct 2005 14:59:44 -0000 1.2 @@ -40,6 +40,7 @@ find . -maxdepth 1 -type d \( \ -name 'common' -o \ -name 'css' -o \ + -name 'packaging' -o \ -name 'stylesheet-images' \) | xargs -i \ find {} -maxdepth 1 -type f ! \( \ -name '.*' -o -name '*~' -o \ From fedora-docs-commits at redhat.com Wed Oct 12 14:59:46 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Wed, 12 Oct 2005 10:59:46 -0400 Subject: docs-common/packaging fedora-documentation.menu, NONE, 1.1 fedora-doc-common.spec, 1.1, 1.2 fedora-doc.desktop.in.common, 1.2, 1.3 Message-ID: <200510121500.j9CF0GRg026347@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/docs-common/packaging In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv26305/packaging Modified Files: fedora-doc-common.spec fedora-doc.desktop.in.common Added Files: fedora-documentation.menu Log Message: Fix packaging to properly add menu and desktop files --- NEW FILE fedora-documentation.menu --- Applications Documentation Documentation.directory X-Fedora-Documentation Index: fedora-doc-common.spec =================================================================== RCS file: /cvs/docs/docs-common/packaging/fedora-doc-common.spec,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- fedora-doc-common.spec 12 Oct 2005 00:09:41 -0000 1.1 +++ fedora-doc-common.spec 12 Oct 2005 14:59:43 -0000 1.2 @@ -35,6 +35,10 @@ install -d -m 755 $RPM_BUILD_ROOT/%{_datadir}/fedora/doc/docs-common/css/ install -m 644 $RPM_BUILD_DIR/%{name}-%{release}/css/* \ $RPM_BUILD_ROOT/%{_datadir}/fedora/doc/docs-common/css/ +install -d -m 755 $RPM_BUILD_ROOT/%{_sysconfdir}/xdg/menus/applications-merged/ +install -m 644 \ + $RPM_BUILD_DIR/%{name}-%{release}/packaging/fedora-documentation.menu \ + $RPM_BUILD_ROOT/%{_sysconfdir}/xdg/menus/applications-merged/ install -d -m 755 $RPM_BUILD_ROOT/%{_datadir}/fedora/doc/docs-common/stylesheet-images/ install -m 644 $RPM_BUILD_DIR/%{name}-%{release}/stylesheet-images/* \ $RPM_BUILD_ROOT/%{_datadir}/fedora/doc/docs-common/stylesheet-images/ @@ -50,6 +54,6 @@ %{_datadir}/fedora/doc/docs-common/common/* %{_datadir}/fedora/doc/docs-common/css/* %{_datadir}/fedora/doc/docs-common/stylesheet-images/* - +%{_sysconfdir}/xdg/menus/applications-merged/* %changelog Index: fedora-doc.desktop.in.common =================================================================== RCS file: /cvs/docs/docs-common/packaging/fedora-doc.desktop.in.common,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- fedora-doc.desktop.in.common 3 Oct 2005 02:38:12 -0000 1.2 +++ fedora-doc.desktop.in.common 12 Oct 2005 14:59:43 -0000 1.3 @@ -1,6 +1,6 @@ [Desktop Entry] Encoding=UTF-8 -Categories=Application;Documentation;X-Red-Hat-Base; +Categories=X-Fedora-Documentation; Name=@TITLE@ GenericName=@TITLE@ Exec=gnome-help file:///usr/share/fedora/doc/fedora-doc- at DOCBASE@/C/@DOCBASE at -en.xml From fedora-docs-commits at redhat.com Wed Oct 12 15:00:45 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Wed, 12 Oct 2005 11:00:45 -0400 Subject: docs-common/packaging titlegrab.py,1.1,1.2 Message-ID: <200510121500.j9CF0j3U026377@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/docs-common/packaging In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv26358/packaging Modified Files: titlegrab.py Log Message: Fix magic line Index: titlegrab.py =================================================================== RCS file: /cvs/docs/docs-common/packaging/titlegrab.py,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- titlegrab.py 3 Oct 2005 02:32:06 -0000 1.1 +++ titlegrab.py 12 Oct 2005 15:00:42 -0000 1.2 @@ -1,4 +1,4 @@ -#!/usr/bin/python -d +#!/usr/bin/python -tt import sys import xml.dom.minidom from xml.dom.minidom import Node From fedora-docs-commits at redhat.com Wed Oct 12 15:07:29 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Wed, 12 Oct 2005 11:07:29 -0400 Subject: docs-common/common opl.xml,NONE,1.1 Message-ID: <200510121507.j9CF7TJs027801@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/docs-common/common In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv27788/common Added Files: opl.xml Log Message: Add OPL for reference and possible later use --- NEW FILE opl.xml --- Open Publication License v1.0, 8 June 1999
I. REQUIREMENTS ON BOTH UNMODIFIED AND MODIFIED VERSIONS The Open Publication works may be reproduced and distributed in whole or in part, in any medium physical or electronic, provided that the terms of this license are adhered to, and that this license or an incorporation of it by reference (with any options elected by the author(s) and/or publisher) is displayed in the reproduction. Proper form for an incorporation by reference is as follows: Copyright (c) <year> by <author's name or designee>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, vX.Y or later (the latest version is presently available at &url.opl; The reference must be immediately followed with any options elected by the author(s) and/or publisher of the document (see section VI). Commercial redistribution of Open Publication-licensed material is permitted. Any publication in standard (paper) book form shall require the citation of the original publisher and author. The publisher and author's names shall appear on all outer surfaces of the book. On all outer surfaces of the book the original publisher's name shall be as large as the title of the work and cited as possessive with respect to the title.
II. COPYRIGHT The copyright to each Open Publication is owned by its author(s) or designee.
III. SCOPE OF LICENSE The following license terms apply to all Open Publication works, unless otherwise explicitly stated in the document. Mere aggregation of Open Publication works or a portion of an Open Publication work with other works or programs on the same media shall not cause this license to apply to those other works. The aggregate work shall contain a notice specifying the inclusion of the Open Publication material and appropriate copyright notice. SEVERABILITY. If any part of this license is found to be unenforceable in any jurisdiction, the remaining portions of the license remain in force. NO WARRANTY. Open Publication works are licensed and provided "as is" without warranty of any kind, express or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose or a warranty of non-infringement.
IV. REQUIREMENTS ON MODIFIED WORKS All modified versions of documents covered by this license, including translations, anthologies, compilations and partial documents, must meet the following requirements: The modified version must be labeled as such. The person making the modifications must be identified and the modifications dated. Acknowledgement of the original author and publisher if applicable must be retained according to normal academic citation practices. The location of the original unmodified document must be identified. The original author's (or authors') name(s) may not be used to assert or imply endorsement of the resulting document without the original author's (or authors') permission.
V. GOOD-PRACTICE RECOMMENDATIONS In addition to the requirements of this license, it is requested from and strongly recommended of redistributors that: If you are distributing Open Publication works on hardcopy or CD-ROM, you provide email notification to the authors of your intent to redistribute at least thirty days before your manuscript or media freeze, to give the authors time to provide updated documents. This notification should describe modifications, if any, made to the document. All substantive modifications (including deletions) be either clearly marked up in the document or else described in an attachment to the document. Finally, while it is not mandatory under this license, it is considered good form to offer a free copy of any hardcopy and CD-ROM expression of an Open Publication-licensed work to its author(s).
VI. LICENSE OPTIONS The author(s) and/or publisher of an Open Publication-licensed document may elect certain options by appending language to the reference to or copy of the license. These options are considered part of the license instance and must be included with the license (or its incorporation by reference) in derived works. A. To prohibit distribution of substantively modified versions without the explicit permission of the author(s). "Substantive modification" is defined as a change to the semantic content of the document, and excludes mere changes in format or typographical corrections. To accomplish this, add the phrase `Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder.' to the license reference or copy. B. To prohibit any publication of this work or derivative works in whole or in part in standard (paper) book form for commercial purposes is prohibited unless prior permission is obtained from the copyright holder. To accomplish this, add the phrase 'Distribution of the work or derivative of the work in any standard (paper) book form is prohibited unless prior permission is obtained from the copyright holder.' to the license reference or copy.
From fedora-docs-commits at redhat.com Wed Oct 12 22:41:52 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Wed, 12 Oct 2005 18:41:52 -0400 Subject: mirror-tutorial mirror-tutorial-en.xml,1.10,1.11 Message-ID: <200510122241.j9CMfqUp010457@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/mirror-tutorial In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv10438 Modified Files: mirror-tutorial-en.xml Log Message: Major changes to simplify, more on the way... Index: mirror-tutorial-en.xml =================================================================== RCS file: /cvs/docs/mirror-tutorial/mirror-tutorial-en.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- mirror-tutorial-en.xml 18 Sep 2005 22:43:44 -0000 1.10 +++ mirror-tutorial-en.xml 12 Oct 2005 22:41:50 -0000 1.11 @@ -5,7 +5,10 @@ %FEDORA-ENTITIES-EN; - + + + + @@ -158,6 +161,16 @@ + + 0.32 + 2005-10-12 + PaulWFrields + + + Fix default network sharing protocol (#169581, #169584) + + + @@ -305,7 +318,7 @@ Naming conventions Throughout the rest of the document, - /var/ftp/pub/mirror represents the folder where + /var/www/mirror represents the folder where all your mirrored files are stored. You may substitute a different location. This location simplifies sharing your mirror, due to the shipping configuration of &FC;. See @@ -332,17 +345,14 @@ RPM packages - RPM - RPM - , originally the Red Hat Package Manager and now the RPM - Package Manager, is not just a file format. RPM is also a system which - tracks and interconnects software and version information. The RPM - system is quite popular, and many other Linux distributions use RPM as - well. Read more information on RPM at http://www.rpm.org/. This document - contains helpful hints on making the most of RPM, in and - . + RPM RPM + , originally the Red Hat Package Manager and now + the RPM Package Manager, is not just a file format. RPM is + also a system which tracks and interconnects software and + version information. The RPM system is quite popular, and many + other Linux distributions use RPM as well. Read more + information on RPM at http://www.rpm.org/. @@ -381,7 +391,7 @@ -cd /var/ftp/pub/mirror/fedora/linux/core/&FCVER;/i386/os/Fedora +cd /var/www/mirror/fedora/linux/core/&FCVER;/i386/os/Fedora ln ../../SRPMS SRPMS @@ -408,7 +418,7 @@ -/path/i386/iso/FC&FCVER;-i386-disc1.iso /path/i386/os/disc1 iso9660 defaults 0 0 +/path/i386/iso/FC&FCVER;-i386-disc1.iso /path/i386/os/disc1 iso9660 defaults 0 0 @@ -433,7 +443,7 @@ -/path/i386/iso/FC&FCVER;-i386-DVD.iso /path/i386/os iso9660 defaults 0 0 +/path/i386/iso/FC&FCVER;-i386-DVD.iso /path/i386/os iso9660 defaults 0 0 @@ -564,7 +574,7 @@ -cd /var/ftp/pub/mirror +cd /var/www/mirror wget --mirror -np -nH --cut-dirs=2 http://mirror.example.com/pub/mirror/fedora/linux/core/&FCVER;/ @@ -665,7 +675,7 @@ -rsync filehouse.example.org::files/misc/ /var/ftp/pub/misc/ +rsync filehouse.example.org::files/misc/ /var/www/misc/ @@ -717,7 +727,7 @@ -rsync -PHav mirror.example.org::fedora-linux-core/&FCVER;/ /var/ftp/pub/mirror/fedora/core/&FCVER; +rsync -PHav mirror.example.org::fedora-linux-core/&FCVER;/ /var/www/mirror/fedora/linux/core/&FCVER; @@ -877,11 +887,11 @@ rsync -Pan --delete --exclude "**x86_64**" --exclude "**headers**" \ --exclude "**debug**" --exclude "**iso**" \ mirror.example.com::fedora-linux-core/&FCVER;/ \ - /var/ftp/pub/mirror/fedora/core/&FCVER; + /var/www/mirror/fedora/core/&FCVER; - +
@@ -951,638 +961,264 @@
- Server Configuration Planning - - Decide what services your mirror will offer to clients. There are at least - three services useful for providing &FED; installation and update - services: HTTP, FTP, and NFS. Some or all of these services can be used - for offering post-installation functions such as updates or installing - additional packages. - - - Install the vsftpd package for FTP services. Install - the httpd package to use the Apache HTTP server. Most - &FC; systems already have the nfs-utils package - installed, which contains the NFS server. - - - To start a service, use the /sbin/service - service start command. To enable that - server by default at boot time, use the chkconfig - service on command. - - - One recommended method is to download all mirrored files into - /var/ftp/pub, add a link in - /var/www/html that points to - /var/ftp/pub, and share out - /var/ftp/pub via NFS as well. FTP and HTTP services - do not require any further configuration to work properly. - However, you should evaluate your site's security needs before - enabling them. NFS service configuration is explained below - in . - - - To share out the public FTP area via HTTP, issue the following - command: - - - -ln -s /var/ftp/pub /var/www/html/pub - - - - Your clients may now visit any area of your mirror by using the URL - http://server.mydomain.org/pub/path. To create - an NFS share, add a line to /etc/exports. This - example shares out the &FC; &FCVER; i386 stock distribution with read-only - access for any host in the mydomain.org - domain. - - - -/var/ftp/pub/linux/fedora/core/&FCVER;/i386/os *.mydomain.org(ro,sync,root_squash) - + Server Configuration - To reread the NFS server configuration files and export the new share, use - the following command: + This section gives guidance on setting up a HTTP (Web) server that + provides installation and update mirror services. - -exportfs -ar - - - - Refer to for a list of commands for - starting services both on demand and at boot time. - - -
- How to Solve Dependencies - - Every RPM package has a header that contains all - the vital information about that package. This information includes - name, version and release, contents, the capabilities provided by the - package, and any prerequisites. These prerequisites may include - dependencies - dependencies - . A dependency is a requirement for one or more additional - packages. - - - Packages installed without satisfying their dependencies may not work - correctly. Dependencies may create a problem for users who are trying to - install a single package. Manually determining and resolving - dependencies is difficult. &FC; provides the - yum utility for solving these - dependencies automatically, providing an improved user experience. - +
+ Setting Up Apache - The Yellow Dog Updater Modified, or - yum yum - , is a Python-based system for computing and solving - RPM dependencies. A yum client retrieves a - cache of headers from its repository server, as well as a list - of available RPM packages and their exact locations on the - server. It can do this via HTTP or FTP, as well as using - standard file system calls (either local or remote via NFS). The - client computes solutions to any package dependencies using the - downloaded header information, and simply requests all necessary - RPM packages once it has finished. The yum - command relies on rpm functions to perform - many of the computations involved in the process. - - - A drawback to yum is that the first time it - is run, it must download a header for every package installed on - the system in order to determine available updates. However, - running a local mirror nullifies this drawback. The - yum command can, of course, download many - megabytes of headers almost instantly on a standard Ethernet - LAN. The yum utility is the most popular - update method for &FC;. - - - For more information about using yum, refer - to . + The HTTP service, provided by the Apache server in the + httpd package, is the easiest service to + configure. You can also use Apache to offer post-installation + functions such as updates or installing additional packages. To + install the httpd package, if you have not + already done so, use the following command: -
- -
- Configuring Repositories - - A yum repository - repository - yum - is a collection of packages on a server which supports - yum clients. Repositories can serve both types of - clients if desired. - + +su - -c "yum install httpd" + - To set up a yum repository, you must write a - directory that contains information which the clients require to resolve - RPM dependencies. The directory's name depends on the version of - yum it supports. It is permissible to have both kinds - of repository information in a single repository. - - - To support older yum clients, use the - yum-arch command. To support current - yum clients, use the - createrepo command. + Next, create a configuration file + /etc/httpd/conf.d/mirror.conf for your + mirror files. The following listing is an example: - - Supporting &FC; 3 and beyond - - &FC; 3 ships with a newer version of yum. - To support &FC; 3 yum clients, you - must use createrepo on - your server's repositories. - - -
- <command>yum-arch</command> - - A directory which supports older versions of yum - (before 2.2) is named headers. It is created by - using the command yum-arch, which is run against - the directory under which you want the - headers directory to appear. The - yum-arch program searches recursively through that - directory and any subdirectories for RPM packages, and includes them - in the header data. - + + Apache 2.x configuration file for installation + mirror -yum-arch -l -s /var/ftp/pub/linux/fedora/core/&FCVER;/i386/os - - - - The -l switch follows symbolic links. The - -s switch includes SRPMS (source RPM packages) in - the header list. The command above creates the yum - header cache in the directory - /var/ftp/pub/linux/fedora/core/&FCVER;/i386/os/headers. - -
+ - <command>createrepo</command> - - The createrepo command creates repository - information to support newer versions of yum (and - possibly other repository client programs). The - createrepo command stores this data in a folder - named repodata. Just as with - yum-arch, run createrepo against - the directory under which you want the - repodata directory to appear. The - createrepo program also searches recursively for - RPM packages to include in the repository data. - - - The following command creates the repository data in the directory - /var/ftp/pub/linux/fedora/core/&FCVER;/i386/os/repodata. - +# Share options for the installation tree. +# Only allow connections from the local host and machines +# whose IP addresses start with 192.168.1 - -createrepo /var/ftp/pub/linux/fedora/core/&FCVER;/i386/os + + AllowOverride None + Order Deny,Allow + Deny from all + Allow from 127.0.0.1 192.168.1 + Options Indexes +]]> - - You may not be able to foresee all the possible uses for your server's - repositories. To minimize problems for your clients, create both kinds - of repository data for any repositories. - - -
- -
- Repository Locations - - Typically yum-arch or createrepo - is run against at least the following locations: - - - - - The stock distribution; for example, - /var/ftp/pub/linux/fedora/core/&FCVER;/i386/os/. - For yum-arch use the -l and - -s options to follow the linked directory - SRPMS and include the source packages - therein. - - - - - Official updates to the distribution; for example, - /var/ftp/pub/linux/fedora/core/updates/&FCVER;/. - Once again, for yum-arch use - -l and/or -s if appropriate. - - - -
- -
- -
- Configuring NFS - - Some client-side utilities also resolve dependencies automatically. - These utilities require more detailed configuration of the client - workstation. For more information, see below. These utilities, however, require - standard file system access to package collections. For this reason, you - may require NFS on your mirror. Configuration of the client depends - in large part on how you decide to implement NFS sharing on the mirror. - - - It is difficult to share subdirectories of other shared directories. - Therefore, think of your mirror as offering many services, each one to - be considered for NFS sharing. For example, share both the stock - distribution of &FC; 2 and the stock distribution of &FC; 3. - - - The client side tools discussed later can use a directory of ISO images - or an exploded tree of package data (see ). You may share out any or - all of these, provided your shares do not clash as described above. - - - + - To share via NFS, edit the /etc/exports file. A - typical share, exported with read-only access for any host on any - network, looks like this: + To start the httpd service, use the following + command: -/mnt/media *(ro,all_squash,async) +/sbin/service httpd start - The all_squash option ensures that no users accessing - the share using their local root account receive equivalent access on - the share. This feature keeps some small measure of security even on a - public share, since a file readable only by root on the server is not - readable by an NFS client. The async option allows - asynchronous read/writes, which is not dangerous in this case because - the share is read-only. The * is a host designator, - in this case matching any host name or IP address. You may wish to - restrict this share to your internal network. You may declare either a - matching name or IP address specification. You can find more detailed - information by reading the man pages for the - /etc/exports file by using the command man - 5 exports. - - - Access control format - - Be certain that you do not have a space between the host specification - and the option listing in parentheses ( - ). A space causes the NFS daemon to consider that - entry as two separate access controls. In the - example above, a space causes the first access control to match all - hosts and allow write access, which is the default! The second access - control is never reached because the first matches any host first. - - - - To share the proper directories from your mirror, use one of the - following forms. To share your exploded tree, export the directory that - contains the &FED; folder (note the capitalization). For i386 - architectures: + To enable that server by default at boot time, use the following + command: -/var/ftp/pub/linux/fedora/core/&FCVER;/i386/os *(ro,all_squash,async) +chkconfig httpd on - To share a directory full of ISO images, export that directory: + Your clients may now visit any area of your mirror by using the + URL + http://server.mydomain.org/mirror/path. - -/var/ftp/pub/linux/fedora/core/&FCVER;/i386/iso *(ro,all_squash,async) - - - +
+ Configuring Repositories + + A yum + repository + repository yum + is a collection of packages on a server which + supports yum clients. Repositories can serve + both types of clients if desired. + + + To set up a yum repository, you must write a + directory that contains information which the clients require to + resolve RPM dependencies. The directory's name depends on the + version of yum it supports. It is permissible + to have both kinds of repository information in a single + repository. + + + To support older yum clients, use the + yum-arch command. To support current + yum clients, use the + createrepo command. + + + Supporting &FC; 3 and beyond - Once you have edited the /etc/exports file, make - sure that the NFS server is installed and started properly on the - mirror. The portmap and - nfs-utils packages must be installed. Configure - them to be turned on at boot time by default. + &FC; 3 ships with a newer version of yum. To + support &FC; 3 yum clients, you + must use createrepo on + your server's repositories. + - -/sbin/chkconfig portmap on -/sbin/chkconfig nfslock on -/sbin/chkconfig nfs on - - +
+ <command>yum-arch</command> - To check if any of these services are currently running, use the - /sbin/service service_name - status command: + A directory which supports older versions of + yum (before 2.2) is named + headers. It is created by using the command + yum-arch, which is run against the directory + under which you want the + headers directory to appear. The + yum-arch program searches recursively through + that directory and any subdirectories for RPM packages, and + includes them in the header data. -/sbin/service portmap status -/sbin/service nfslock status -/sbin/service nfs status +yum-arch -l -s /var/www/mirror/fedora/linux/core/&FCVER;/i386/os - To restart a service, use the /sbin/service - service_name restart command: + The -l switch follows symbolic links. The + -s switch includes SRPMS (source RPM + packages) in the header list. The command above creates the + yum header cache in the directory + /var/www/mirror/fedora/linux/core/&FCVER;/i386/os/headers. +
- -/sbin/service portmap restart -/sbin/service nfslock restart -/sbin/service nfs restart - - +
+ <command>createrepo</command> + + The createrepo command creates repository + information to support newer versions of yum + (and possibly other repository client programs). The + createrepo command stores this data in a + folder named repodata. Just as with + yum-arch, run createrepo + against the directory under which you want + the repodata directory to appear. The + createrepo program also searches recursively + for RPM packages to include in the repository data. + - If any service is not started, use the command /sbin/service - service_name start to start it, as - in the following examples: + The following command creates the repository data in the + directory + /var/www/mirror/fedora/linux/core/&FCVER;/i386/os/repodata. -/sbin/service portmap start -/sbin/service nfslock start -/sbin/service nfs start +createrepo /var/www/mirror/fedora/linux/core/&FCVER;/i386/os - To change your exports when the NFS service is already running, use the - command /usr/sbin/exportfs -ar. The command - /usr/sbin/showmount -e displays a list of the - current NFS exports on the local host machine. + You may not be able to foresee all the possible uses for your + server's repositories. You may have certain clients who update + their version of yum in a non-prescribed way. + To minimize problems for your clients, create both kinds of + repository data for any repositories. The extra repository + information is relatively small and will not affect your + mirror's proper function.
-
- -
- Client Configuration - - You must also correctly configure the client workstations that use your - mirror. Using the mirror as a source for RPM packages, clients may have - seamless access for installing basic software through - system-config-packages, solving RPM package - installations at the command line, and pulling bug fix and security errata - updates. - - -
- Configuring <application>system-config-packages</application> +
+ Repository Locations - Users typically run the - system-config-packages application from the - GUI menu, by choosing System Settings, - Add/Remove Applications. This program allows - the user to change the stock installation, provided no updates have - taken place yet that interfere. - - - Often, system-config-packages stops - functioning optimally after certain updates are installed. This is - because system-config-packages solves - dependencies based on the stock distribution. It is impossible for - system-config-packages to predict version - numbers of updates. If you intend to carry updates on your mirror, you - should be aware that installing certain updates causes - system-config-packages to lose its - effectiveness. Some sites do not mirror all updates due to configuration - management concerns. The guidance in this section is especially useful - in those scenarios. - - - - <command>yum</command> and - <application>system-config-packages</application> - - If you plan to carry updates on your mirror, as most administrators - do, you will probably not use - system-config-packages much. Once the - installed package versions become out of sync with the original - distribution versions, yum becomes much - more useful. The preferred method for installing a package in that - case would be yum install - package_name. See for more information. - - - -
- Setting Up <command>autofs</command> - - The autofs - autofs - facility allows a &FC; system to mount file systems on - demand. The /etc/auto.master file contains an - automounter map - automounter map - - - map - automounter - automounter map - . On &FC;, the automounter map is a list of additional - definition files that should be loaded, one for each directory in the - map. An example line from /etc/auto.master is - shown below: - - - -/misc /etc/auto.misc --timeout=60 - - - - The first term in the line is the directory which is reserved for - automounting. The second term is the automount file which should be - consulted to determine any maps for that directory. The third term in - the example indicates that if a map under /misc is not busy for 60 - seconds, it is unmounted. - - - The /etc/auto.misc file contains entries similar - to the following example. - - - -remote -ro,soft,intr host.foobar.org:/pub - - - - This line is contained in the automounter map file for the - /misc directory. The first term is a key which is - the name of a directory that appears upon demand. The second term is - actually a list of options, identical to those that would be used for - a real mount command. The final term is the file - system (local or remote) to mount. In the above example, if the user - of this station accesses the directory - /misc/remote, an NFS mount is automatically - performed. The user's command appears to hesitate, depending on how - fast the NFS server responds. Then /misc/remote - appears to be full of whatever content is on host.foobar.org in the - /pub NFS share. - - - You can use this function to provide NFS access to the stock - distribution for &FC;. Choose a directory to map in the - /etc/auto.master file, and match it to a - corresponding automounter map file. The easiest way to do this is to - simply remove the comment # from the - front of the line attaching /misc to - /etc/auto.misc. The default timeout should be - sufficient. - - - Make an entry in /etc/auto.misc similar to - this. You can have multiple entries, each one with a different - key. For instance, each key could be mapped to a different version of - &FC; that you have available on the local mirror. - - - -fc&FCVER; -ro,soft,intr mirror.mydomain.org:/var/ftp/pub/linux/fedora/core/&FCVER; - - - - Now restart the autofs service: - - - -/sbin/service autofs restart - - - - To access the stock distribution for &FC; &FCVER; the user can simply - type cd /misc/fc&FCVER;. The share is automatically - mounted and the files simply appear in that local directory. - - -
- -
- <filename>/usr/share/applications/system-config-packages</filename> - - Now that autofs has been configured, your client - workstations need to be configured so that - system-config-packages points to the - mirror's NFS share. Edit the - /usr/share/applications/system-config-packages - file's Exec= line to add a switch pointing to the - share: - - - -Exec=/usr/bin/system-config-packages --tree=/misc/fc&FCVER;/i386/os - - - - When users choose System Settings, - Add/Remove Applications from the GUI main - menu, the system now automatically resolves package dependencies from - the mirror. The restrictions stated above in apply. - -
- -
- The <command>rpm --aid</command> Switch - - The --aid switch for the rpm - command also automatically solves dependencies. It performs this - function based on the rpmdb-fedora package. That - package is a preset database for a system that has every RPM package - in the &FC; distribution installed. Even if a system does not - itself have every package installed, it can - consult the rpmdb-fedora package database to see - what such a system would look like. By using the - --aid switch, clients can issue a single - rpm --install --aid command against an original - &FC; package, and have all dependencies automatically installed as - well. - - - Two steps are required for this process. First, install the - rpmdb-fedora package: - - - -rpm --install /misc/fc&FCVER;/i386/os/&FED;/RPMS/rpmdb-fedora-*.rpm - - - - Then, edit the file /etc/rpm/macros.solve, which - is part of the rpmdb-fedora package. Change the - following lines to enable package resolution: - - - -%_solve_pkgsdir /misc/fc&FCVER;/i386/os/&FED;/RPMS/ -%_solve_name_fmt %{?_solve_pkgsdir}%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm - - - - Users now issue a single command to install any package from - the stock distribution, and all dependencies are solved for - them. For example: - - - -rpm --install --aid /misc/fc&FCVER;/i386/os/&FED;/RPMS/kdeutils-*.rpm - - - - If a user forgets the --aid switch, they still - receive hints. Normally rpm displays a slightly - cryptic list of capability requirements, instead of straightforward - package names. If you edit /etc/rpm/macros.solve - as shown, rpm displays a list of required package - names instead. - - - Package dependency solutions using --aid are also - restricted as shown above in . - - -
+ Typically yum-arch or + createrepo is run against at least the + following locations: + + + + + The stock distribution; for example, + /var/www/mirror/fedora/linux/core/&FCVER;/i386/os/. + For yum-arch use the + -l and -s options to + follow the linked directory SRPMS and + include the source packages therein. + + + + + Official updates to the distribution; for example, + /var/mirror/fedora/linux/core/updates/&FCVER;/. + Once again, for yum-arch use + -l and/or -s if + appropriate. + + + +
From fedora-docs-commits at redhat.com Thu Oct 13 11:34:50 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Thu, 13 Oct 2005 07:34:50 -0400 Subject: yum-software-management yum-software-management-en.xml,1.47,1.48 Message-ID: <200510131134.j9DBYobi031631@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/yum-software-management In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv31612 Modified Files: yum-software-management-en.xml Log Message: Fix wording (#170584), push to 1.0.3 Index: yum-software-management-en.xml =================================================================== RCS file: /cvs/docs/yum-software-management/yum-software-management-en.xml,v retrieving revision 1.47 retrieving revision 1.48 diff -u -r1.47 -r1.48 --- yum-software-management-en.xml 4 Sep 2005 13:53:03 -0000 1.47 +++ yum-software-management-en.xml 13 Oct 2005 11:34:47 -0000 1.48 @@ -4,7 +4,7 @@ %FEDORA-ENTITIES-EN; - + @@ -88,6 +88,16 @@ + + 1.0.3 + 2005-10-13 + PaulWFrields + + + Fix wording (#170584). + + + @@ -582,7 +592,7 @@ The yum utility is a complete software - management system. &FC; also includes other several other + management system. &FC; also includes several other applications that can supplement yum. From fedora-docs-commits at redhat.com Sat Oct 15 15:54:59 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Sat, 15 Oct 2005 11:54:59 -0400 Subject: mirror-tutorial mirror-tutorial-en.xml,1.11,1.12 Message-ID: <200510151554.j9FFsx4c022412@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/mirror-tutorial In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv22393 Modified Files: mirror-tutorial-en.xml Log Message: Some style and content changes, bump to 0.33 Index: mirror-tutorial-en.xml =================================================================== RCS file: /cvs/docs/mirror-tutorial/mirror-tutorial-en.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- mirror-tutorial-en.xml 12 Oct 2005 22:41:50 -0000 1.11 +++ mirror-tutorial-en.xml 15 Oct 2005 15:54:57 -0000 1.12 @@ -6,8 +6,8 @@ %FEDORA-ENTITIES-EN; - - + + @@ -171,6 +171,16 @@ + + 0.33 + 2005-10-15 + PaulWFrields + + + Some style changes and more indexing + + + @@ -180,11 +190,12 @@ Purpose This tutorial presents a number of related topics that allow an - administrator to seamlessly integrate mirroring and update services for - &FC;. You can use these services to provision a classroom, laboratory, - or office. These service provisions also increase ease of use and - enhance user experience, adding to the perceived value of - non-proprietary operating systems and software. + administrator to seamlessly integrate mirroring and update + services for &FC;. Use these services to provision a classroom, + laboratory, or office. These service provisions also increase + ease of use and enhance user experience. They also add to the + perceived value of non-proprietary operating systems and + software. &BUG-REPORTING;
@@ -192,18 +203,18 @@ Audience You will find this tutorial more useful if you are a system - administrator, or a &FC; power user familiar with the - following topics: + administrator, or a &FC; power user familiar with + the following topics: - &FC; system installation + &FC; system installation and administration - Basic Internet protocols (HTTP/Web, FTP) + Basic Internet protocols (HTTP/Web) @@ -217,43 +228,45 @@ About Mirrors A mirror - mirror is a server that - provides a copy of one or more collections of files. Mirroring a site - reduces traffic to the original source site, thus spreading the stress - and bandwidth costs of many users across many sites. Side benefits of - running a local mirror include very fast access through the local - network, providing custom services to local users, and increasing your - skills in managing Internet services. - - - The site from which you retrieve files to build your mirror is called an - upstream mirror - mirror upstream - . If possible, choose an upstream mirror that is located - close to you geographically. This reduces unnecessary traffic across - transcontinental sections of the Internet, where bandwidth is limited - and expensive. Use only upstream mirrors that are intended for public - access, unless you have permission from the upstream mirror site - administrator. + mirror is a server + that provides a copy of one or more collections of files. + Mirroring a site reduces traffic to the original source site, + thus spreading the stress and bandwidth costs of many users + across many sites. Side benefits of running a local mirror + include very fast access through the local network, providing + custom services to local users, and increasing your skills in + managing Internet services. + + + The site from which you retrieve files to build your mirror is + called an upstream mirror + mirror upstream + . If possible, choose an upstream mirror that is + located close to you geographically. This reduces unnecessary + traffic across transcontinental sections of the Internet, where + bandwidth is limited and expensive. Use only upstream mirrors + that are intended for public access, unless you have permission + from the upstream mirror site administrator.
Additional Resources For more information on installing &FC; see the &FC; &IG; at - &IG-URL;. For more information on basic Internet protocols, see http://library.albany.edu/internet/internet.html, + &IG-URL;. For more information on basic Internet protocols, see + http://library.albany.edu/internet/internet.html, or search Google at http://www.google.com/. For more - general information about mirrors, see http://en.wikipedia.org/wiki/Mirror_(computing). + url="http://www.google.com/">http://www.google.com/. + For more general information about mirrors, see http://en.wikipedia.org/wiki/Mirror_(computing).
Acknowledgements - Karsten Wade provided editorial services, keeping the style crisp and - consistent. + Karsten Wade provided editorial services and kept the style + crisp and consistent.
@@ -265,13 +278,15 @@ The Distribution Structure The &FED; distribution - distribution - , which is the collection of all &FED;-related files, uses - the directory tree in . It may - include multiple versions of &FC;. The tree design makes "trimming" of - unnecessary or undesired files easier. When setting up a mirror, - duplicate this tree exactly, or as closely as possible. Doing so makes - automating nightly updates easier. + distribution + , which is the collection of all &FED;-related + files, uses the directory tree in . It may include multiple + versions of &FC;. The tree design makes it easier to "trim" + unnecessary or undesired files. When you set up a mirror, + duplicate this tree exactly, or as closely as possible. If you + duplicate the tree, it will be easier to automate nightly + updates. @@ -318,13 +333,13 @@ Naming conventions Throughout the rest of the document, - /var/www/mirror represents the folder where - all your mirrored files are stored. You may substitute a different - location. This location simplifies sharing your mirror, due to the - shipping configuration of &FC;. See - for more information. The site name - mirror.example.com represents the - upstream mirror. + /var/www/mirror represents the folder + where all your mirrored files are stored. You may substitute a + different location. This location simplifies sharing your + mirror, due to the shipping configuration of &FC;. See for more information. The site + name mirror.example.com + represents the upstream mirror. @@ -348,7 +363,7 @@ RPM RPM , originally the Red Hat Package Manager and now the RPM Package Manager, is not just a file format. RPM is - also a system which tracks and interconnects software and + also a system that tracks and interconnects software and version information. The RPM system is quite popular, and many other Linux distributions use RPM as well. Read more information on RPM at - The SRPMS folders under architecture-specific - branches are links which point to the main SRPMS - folder for that distribution. For example, - fedora/linux/core/2/i386/os/SRPMS is a link which - points to fedora/linux/core/2/SRPMS. + The SRPMS folders under + architecture-specific branches are links that point to the main + SRPMS folder for that distribution. For + example, fedora/linux/core/2/i386/os/SRPMS + is a link that points to + fedora/linux/core/2/SRPMS. A &FED; mirror consists of at least the original ISO images - or the distribution files. If possible, include - both, provided you have sufficient disk space and/or bandwidth. + or the distribution files. If possible, + include both, provided you have sufficient disk space and/or + bandwidth. @@ -373,21 +390,21 @@ Copying the Original Distribution If you already have reliable CD-ROM installation discs of a - distribution, reduce your initial bandwidth and time spent mirroring by - copying the files from the discs to your server. Copy all files from - Installation Disc 1 into the + distribution, reduce your initial bandwidth and time spent + mirroring by copying the files from the discs to your server. + Copy all files from Installation Disc 1 into the fedora/linux/core/&FCVER;/arch/os - folder. Then copy all files from the &FED; folder - of each of the remaining Installation discs into the + folder. Then copy all files from the &FED; + folder of each of the remaining Installation discs into the fedora/linux/core/&FCVER;/arch/os/&FED; folder on the server. - Copy all the files from the SRPMS folder on each of - the Sources discs to the - fedora/linux/core/&FCVER;/SRPMS folder on the - server. Make a link in the os folder that occurs - under each architecture. Follow this example: + Copy all the files from the SRPMS folder on + each of the Sources discs to the + fedora/linux/core/&FCVER;/SRPMS folder on + the server. Make a link in the os folder + that occurs under each architecture. Follow this example: @@ -422,11 +439,12 @@ - The anaconda application automatically - detects these folders and uses them properly. In addition, system - configuration tools such as - system-config-packages also continue to work - properly when pointed at the parent of the ISO image mount points. + The anaconda installer application + automatically detects these folders and uses them properly. In + addition, system configuration tools such as + system-config-packages also continue + to work properly when pointed at the parent of the ISO image + mount points. There are drawbacks to using CD ISO images in this fashion. For @@ -543,33 +561,35 @@ - Unless your site closely manages workstation configuration, you should - probably not trim any of the updates branches for - the distributions you support. These locations contain packages handling - bug fixes, security patches, and errata updates which your users - probably want. + Unless your site closely manages workstation configuration, you + should probably not trim any of the updates + branches for the distributions you support. These locations + contain packages with bug fixes, security patches, and errata + updates that your users probably want.
Downloading the Files - Locate a public mirror site for &FC; by referring to the main project - site's mirror page, &FDP-URL;. Once you have selected a nearby mirror - site, note what services it offers (FTP, HTTP, and/or rsync). A mirror - is usually servicing a large number of users. Choose off-peak hours, - when possible, to download a large set of files. Be aware of any - timezone differences when estimating off-peak hours. + Locate a public mirror site for &FC; by referring to the main + project site's mirror page, &FDP-URL;. Once you have selected a + nearby mirror site, note what services it offers (FTP, HTTP, + and/or rsync). A mirror is usually servicing a large number of + users. Choose off-peak hours, when possible, to download a large + set of files. Be aware of any timezone differences when + estimating off-peak hours.
Download Using HTTP or FTP - To download via HTTP or FTP, use the wget command. - wget recurses subdirectories automatically and - pulls down entire trees of data with a single command. If you are not - careful, however, it is possible to pull down much more data than you - intended. The following commands mirror the entire current &FC; + To download via HTTP or FTP, use the wget + command. wget recurses subdirectories + automatically and pulls down entire trees of data with a + single command. If you are not careful, however, it is + possible to pull down much more data than you intended. The + following commands mirror the entire current &FC; distribution: @@ -584,60 +604,64 @@ - --mirror turns on recursion (descends into all - subdirectories), and duplicates file timestamps; + --mirror turns on recursion (descends + into all subdirectories), and duplicates file timestamps; - -np prevents wget from - ascending into the parent directory; + -np prevents wget + from ascending into the parent directory; - -nH prevents wget from - writing a directory named after the host (in this case, + -nH prevents wget + from writing a directory named after the host (in this + case, mirror.example.com); --cut-dirs=n - truncates the first n directories in - the path. In the example above, --cut-dirs=2 - prevents wget from writing the + truncates the first n + directories in the path. In the example above, + --cut-dirs=2 prevents + wget from writing the /pub/mirror portion of the path into your mirror. - The same syntax works for both HTTP and FTP mirrors. It is possible - that you may download some extraneous files if the HTTP site formats - its pages for browser viewing. These files can be safely deleted, but - return each time the mirror updates unless you exclude them using - special options. See the wget man pages for more - information. + The same syntax works for both HTTP and FTP mirrors. It is + possible that you may download some extraneous files if the + HTTP site formats its pages for browser viewing. These files + can be safely deleted, but return each time the mirror updates + unless you exclude them using special options. See the + wget man pages for more information.
The <command>rsync</command> Command - Use the rsync command to synchronize a set of files - and/or directories with a remote host. It operates in much the same - way as rcp, but it is usually faster. One reason - for the speed is that rsync has a special protocol - that evaluates and skips files (or portions of files) that are already + Use the rsync command to synchronize a set + of files and/or directories with a remote host. It operates in + much the same way as rcp, but it is usually + faster. One reason for the speed is that + rsync has a special protocol that evaluates + and skips files (or portions of files) that are already downloaded. - Begin by identifying the modules available on the upstream mirror site - you have chosen. Note that the double colon :: is - always used after the host name to separate it from the rest of the - rsync path. The following command generates a list - of modules on the upstream mirror. + Begin by identifying the modules available on the upstream + mirror site you have chosen. Note that the double colon + :: is always used after the host name to + separate it from the rest of the rsync + path. The following command generates a list of + modules on the upstream mirror. @@ -645,16 +669,18 @@ - These modules are roughly equivalent to top-level directories, and - they follow the same rules. To list any subdirectory of the upstream - mirror, add the directory path to the command above. For example, on - many mirrors, the fedora-linux-core module is - equivalent to the fedora/linux/core path found at - the &FP; main download server. To list the contents of the &FC; + These modules are roughly equivalent to top-level directories, + and they follow the same rules. To list any subdirectory of + the upstream mirror, add the directory path to the command + above. For example, on many mirrors, the + fedora-linux-core module is equivalent to + the fedora/linux/core path found at the + &FP; main download server. To list the contents of the &FC; &FCVER; distribution folder on the upstream server, issue the - following command. Do not forget the trailing slash /. - Without it, you only receive a listing of a folder name that matches - the last component of the remote path. + following command. Do not forget the trailing slash + /. Without it, you only receive a listing of a + folder name that matches the last component of the remote + path. @@ -666,12 +692,13 @@
Downloading Using <command>rsync</command> - To download via rsync, add a destination path on - your system to the end of the command line. The resulting tree of - files from the listing you perform are downloaded to the local path - you specify. Remember, if you leave off the trailing slash on the - remote path, then the last component of that path is created as a - folder, and its contents are copied. + To download via rsync, add a destination + path on your system to the end of the command line. The + resulting tree of files from the listing you perform are + downloaded to the local path you specify. Remember, if you + leave off the trailing slash on the remote path, then the last + component of that path is created as a folder, and its + contents are copied. @@ -1000,8 +1027,8 @@ Alias /mirror /var/www/mirror # Share options for the installation tree. -# Only allow connections from the local host and machines -# whose IP addresses start with 192.168.1 +# Only allow connections from localhost and +# IP addresses which start with 192.168.1 AllowOverride None @@ -1040,185 +1067,191 @@
-
- Solving Dependencies - - Every RPM package has a header that contains - all the vital information about that package. This information - includes name, version and release, contents, the capabilities - provided by the package, and any prerequisites. These - prerequisites may include - dependencies - dependencies . A dependency is a - requirement for one or more additional packages. - - - Packages installed without satisfying their dependencies may not - work correctly. Dependencies may create a problem for users who - are trying to install a single package. Manually determining and - resolving dependencies is difficult. &FC; provides the - yum utility for solving these dependencies - automatically, providing an improved user experience. - +
+ Solving Dependencies + + Every RPM package has a RPM + header + header that contains all + the vital information about that package. This information + includes name, version and release, contents, the capabilities + provided by the package, and any prerequisites. These + prerequisites may include + dependencies + RPM + dependencies + . A dependency is a requirement for one or more + additional packages. + + + Packages installed without satisfying their dependencies may not + work correctly. Dependencies may create a problem for users who + are trying to install a single package. Manually determining and + resolving dependencies is difficult. &FC; provides the + yum utility for solving these dependencies + automatically, providing an improved user experience. + - + The Yellow Dog Updater Modified, or - yum yum + yum yum , is a Python-based system for computing and solving - RPM dependencies. A yum client retrieves a - cache of headers from its repository server, as well as a list of - available RPM packages and their exact locations on the server. It - can do this via HTTP or FTP, as well as using standard file system - calls (either local or remote via NFS). The client computes - solutions to any package dependencies using the downloaded header - information, and simply requests all necessary RPM packages once - it has finished. The yum command relies on - rpm functions to perform many of the - computations involved in the process. - - - A drawback to yum is that the first time it is - run, it must download a header for every package installed on the - system in order to determine available updates. However, running a - local mirror nullifies this drawback. The yum - command can download many megabytes of headers almost instantly on - a standard Ethernet LAN. The yum utility is the - most popular update method for &FC;. - - - For more information about using yum, refer to - . - + RPM dependencies. A yum client retrieves a + cache of headers from its repository server, as well as a list + of available RPM packages and their exact locations on the + server. It can do this via HTTP or FTP, as well as using + standard file system calls (either local or remote via NFS). The + client computes solutions to any package dependencies using the + downloaded header information, and simply requests all necessary + RPM packages once it has finished. The yum + command relies on rpm functions to perform + many of the computations involved in the process. + + + A drawback to yum is that the first time it + is run, it must download a header for every package installed on + the system in order to determine available updates. However, + running a local mirror nullifies this drawback. The + yum command can download many megabytes of + headers almost instantly on a standard Ethernet LAN. The + yum utility is the most popular update method + for &FC;. + + + For more information about using yum, refer + to . + -
+
-
- Configuring Repositories - +
+ Configuring Repositories + A yum - repository - repository yum - is a collection of packages on a server which - supports yum clients. Repositories can serve - both types of clients if desired. - + repository + repository + is a collection of packages on a server which + supports yum clients. Repositories can serve + both types of clients if desired. + - - To set up a yum repository, you must write a - directory that contains information which the clients require to - resolve RPM dependencies. The directory's name depends on the - version of yum it supports. It is permissible - to have both kinds of repository information in a single - repository. - - - To support older yum clients, use the - yum-arch command. To support current - yum clients, use the - createrepo command. - - - Supporting &FC; 3 and beyond - &FC; 3 ships with a newer version of yum. To - support &FC; 3 yum clients, you - must use createrepo on - your server's repositories. - - - -
- <command>yum-arch</command> - - A directory which supports older versions of - yum (before 2.2) is named - headers. It is created by using the command - yum-arch, which is run against the directory - under which you want the - headers directory to appear. The - yum-arch program searches recursively through - that directory and any subdirectories for RPM packages, and - includes them in the header data. + To set up a yum repository, you must write a + directory that contains information which the clients require to + resolve RPM dependencies. The directory's name depends on the + version of yum it supports. It is permissible + to have both kinds of repository information in a single + repository. + + + To support older yum clients, use the + yum-arch command. To support current + yum clients, use the + createrepo command. + + Supporting &FC; 3 and beyond + + &FC; 3 ships with a newer version of yum. + To support &FC; 3 yum clients, you + must use createrepo on + your server's repositories. + + + +
+ <command>yum-arch</command> + + A directory which supports older versions of + yum (before 2.2) is named + headers. It is created by using the + command yum-arch, which is run against the + directory under which you want the + headers directory to appear. The + yum-arch program searches recursively + through that directory and any subdirectories for RPM + packages, and includes them in the header data. + yum-arch -l -s /var/www/mirror/fedora/linux/core/&FCVER;/i386/os - - The -l switch follows symbolic links. The - -s switch includes SRPMS (source RPM - packages) in the header list. The command above creates the - yum header cache in the directory - /var/www/mirror/fedora/linux/core/&FCVER;/i386/os/headers. - -
+ + The -l switch follows symbolic links. The + -s switch includes SRPMS (source RPM + packages) in the header list. The command above creates the + yum header cache in the directory + /var/www/mirror/fedora/linux/core/&FCVER;/i386/os/headers. + +
-
- <command>createrepo</command> - - The createrepo command creates repository - information to support newer versions of yum - (and possibly other repository client programs). The - createrepo command stores this data in a - folder named repodata. Just as with - yum-arch, run createrepo - against the directory under which you want - the repodata directory to appear. The - createrepo program also searches recursively - for RPM packages to include in the repository data. - - - The following command creates the repository data in the - directory - /var/www/mirror/fedora/linux/core/&FCVER;/i386/os/repodata. - +
+ <command>createrepo</command> + + The createrepo command creates repository + information to support newer versions of + yum (and possibly other repository client + programs). The createrepo command stores + this data in a folder named repodata. + Just as with yum-arch, run + createrepo against the directory + under which you want the + repodata directory to appear. The + createrepo program also searches + recursively for RPM packages to include in the repository + data. + + + The following command creates the repository data in the + directory + /var/www/mirror/fedora/linux/core/&FCVER;/i386/os/repodata. + createrepo /var/www/mirror/fedora/linux/core/&FCVER;/i386/os - - You may not be able to foresee all the possible uses for your - server's repositories. You may have certain clients who update - their version of yum in a non-prescribed way. - To minimize problems for your clients, create both kinds of - repository data for any repositories. The extra repository - information is relatively small and will not affect your - mirror's proper function. - + + You may have certain clients who update their version of + yum in a non-prescribed way. To minimize + problems for your clients, create both kinds of repository + data for any repositories. The extra repository information + is relatively small and will not affect your mirror's proper + function. + -
+
-
- Repository Locations - - Typically yum-arch or - createrepo is run against at least the - following locations: - - - - - The stock distribution; for example, - /var/www/mirror/fedora/linux/core/&FCVER;/i386/os/. - For yum-arch use the - -l and -s options to - follow the linked directory SRPMS and - include the source packages therein. - - - - - Official updates to the distribution; for example, - /var/mirror/fedora/linux/core/updates/&FCVER;/. - Once again, for yum-arch use - -l and/or -s if - appropriate. - - - -
+
+ Repository Locations + + Typically you will run yum-arch or + createrepo against at least the following + locations: + + + + + The stock distribution; for example, + /var/www/mirror/fedora/linux/core/&FCVER;/i386/os/. + For yum-arch, use the + -l and -s options to + follow the linked directory SRPMS and + include the source packages therein. + + + + + Official updates to the distribution; for example, + /var/mirror/fedora/linux/core/updates/&FCVER;/. + Once again, for yum-arch use + -l and/or -s if + appropriate. + + + +
From fedora-docs-commits at redhat.com Mon Oct 17 02:12:17 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Sun, 16 Oct 2005 22:12:17 -0400 Subject: mirror-tutorial mirror-tutorial-en.xml,1.12,1.13 Message-ID: <200510170212.j9H2CHsc021824@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/mirror-tutorial In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv21805 Modified Files: mirror-tutorial-en.xml Log Message: Add client configuration section, bump to 0.34 and republish beta Index: mirror-tutorial-en.xml =================================================================== RCS file: /cvs/docs/mirror-tutorial/mirror-tutorial-en.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- mirror-tutorial-en.xml 15 Oct 2005 15:54:57 -0000 1.12 +++ mirror-tutorial-en.xml 17 Oct 2005 02:12:01 -0000 1.13 @@ -6,8 +6,8 @@ %FEDORA-ENTITIES-EN; - - + + @@ -18,24 +18,15 @@ Mirror Tutorial - <emphasis>BETA</emphasis> - - 2004 - - - Paul W. Frields - + 2004 + 2005 + Paul W. Frields - - Frields - - - Paul - - - W. - + Frields + Paul + W. &LEGALNOTICE; @@ -203,8 +194,8 @@ Audience You will find this tutorial more useful if you are a system - administrator, or a &FC; power user familiar with - the following topics: + administrator, or a &FC; "power user" familiar with the + following topics: @@ -401,7 +392,7 @@ Copy all the files from the SRPMS folder on - each of the Sources discs to the + each of the "Sources" discs to the fedora/linux/core/&FCVER;/SRPMS folder on the server. Make a link in the os folder that occurs under each architecture. Follow this example: @@ -502,15 +493,16 @@ The development folder (formerly - Rawhide). + "Rawhide"). - This folder contains all the latest bleeding-edge + This folder contains all the latest "bleeding-edge" packages from the &FP;. If you participate in active &FED; - development, you should not trim this branch. &FED; development - moves at a rapid pace and requires frequent updates to the latest - development package versions. However, the frequent updates cause - your mirror to download significant amounts of material during the + development, you should not trim this branch. &FED; + development moves at a rapid pace and requires frequent + updates to the latest development package + versions. However, the frequent updates cause your mirror + to download significant amounts of material during the regular update cycle. @@ -519,17 +511,18 @@ The testing folders. - These branches contain updates that are being subjected to quality - assurance through public testing, as well as the test or - pre-release versions of the &FC; distribution. The - testing folder under the main - core tree is where test versions of the - distribution, such as &FC; &FCTESTVER;, are kept. (Users of &FC; - test distributions are often directed to use the - development branch to update packages.) The - testing folder, under - updates, contains package updates that have - not yet passed the public testing phase. + These branches contain updates that are being subjected to + quality assurance through public testing, as well as the + test or "pre-release" versions of the &FC; + distribution. The testing folder + under the main core tree is where + test versions of the distribution, such as &FC; + &FCTESTVER;, are kept. (Users of &FC; test distributions + are often directed to use the + development branch to update + packages.) The testing folder, under + updates, contains package updates + that have not yet passed the public testing phase. @@ -635,12 +628,13 @@ - The same syntax works for both HTTP and FTP mirrors. It is - possible that you may download some extraneous files if the - HTTP site formats its pages for browser viewing. These files - can be safely deleted, but return each time the mirror updates - unless you exclude them using special options. See the - wget man pages for more information. + The same syntax works for both HTTP and FTP upstream + mirrors. It is possible that you may download some extraneous + files if the HTTP site formats its pages for browser + viewing. These files can be safely deleted, but return each + time the mirror updates unless you exclude them using special + options. See the wget man pages for more + information.
@@ -657,11 +651,10 @@ Begin by identifying the modules available on the upstream - mirror site you have chosen. Note that the double colon - :: is always used after the host name to - separate it from the rest of the rsync - path. The following command generates a list of - modules on the upstream mirror. + mirror site you have chosen. Note that the double colon "::" + is always used after the host name to separate it from the + rest of the rsync path. The following + command generates a list of "modules" on the upstream mirror. @@ -677,10 +670,9 @@ the fedora/linux/core path found at the &FP; main download server. To list the contents of the &FC; &FCVER; distribution folder on the upstream server, issue the - following command. Do not forget the trailing slash - /. Without it, you only receive a listing of a - folder name that matches the last component of the remote - path. + following command. Do not forget the trailing slash "/". + Without it, you only receive a listing of a folder name that + matches the last component of the remote path. @@ -758,11 +750,11 @@ - The -n switch performs a dry run - using the other given parameters. Use this switch to test any - rsync command if you are unsure what files you will - receive. See also . + The -n switch performs a "dry run" using + the other given parameters. Use this switch to test any + rsync command if you are unsure what files + you will receive. See also . The -z switch enables compression during the @@ -1257,6 +1249,48 @@
+
+ Client Configuration + + + Client systems that use yum to contact your + mirror also require configuration. The yum + repository configuration files are located in + /etc/yum.repos.d and end with the suffix + .repo. Below is an example configuration + file. + + + + Example + <filename>/etc/yum.repos.d/fedora.repo</filename> + + +[base] +name=Fedora Core $releasever - $basearch - Base +baseurl=http://server.mydomain.net/mirror/fedora/linux/core/$releasever/$basearch +enabled=1 +gpgcheck=1 +gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora + + + + + + Client systems should use a repository configuration file for each + &FED; branch your mirror provides. The base distribution and + released updates, for example, each require a separate + configuration file. + + + + For more information about these configuration files, refer to the + "Software Management with yum" tutorial online + at . + + +
+ + From fedora-docs-commits at redhat.com Tue Oct 18 23:07:48 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Tue, 18 Oct 2005 19:07:48 -0400 Subject: docs-common/common opl.xml,1.1,1.2 Message-ID: <200510182307.j9IN7mMD004973@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/docs-common/common In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv4952 Modified Files: opl.xml Log Message: Modified to import sucessfully into documents. It may preferable to use a smaller notice that links to an online copy of the OPL, similar to legalnotice-content.xml Index: opl.xml =================================================================== RCS file: /cvs/docs/docs-common/common/opl.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- opl.xml 12 Oct 2005 15:07:12 -0000 1.1 +++ opl.xml 18 Oct 2005 23:07:37 -0000 1.2 @@ -1,201 +1,219 @@ -Open Publication License - - v1.0, 8 June 1999 - -
- I. REQUIREMENTS ON BOTH UNMODIFIED AND MODIFIED - VERSIONS - - - The Open Publication works may be reproduced and distributed in - whole or in part, in any medium physical or electronic, provided - that the terms of this license are adhered to, and that this license - or an incorporation of it by reference (with any options elected by - the author(s) and/or publisher) is displayed in the reproduction. - - - - Proper form for an incorporation by reference is as follows: - - - - Copyright (c) <year> by <author's name or designee>. - This material may be distributed only subject to the terms and - conditions set forth in the Open Publication License, vX.Y or later - (the latest version is presently available at &url.opl; - - - - The reference must be immediately followed with any options elected - by the author(s) and/or publisher of the document (see section - VI). Commercial redistribution of Open Publication-licensed material - is permitted. Any publication in standard (paper) book form shall - require the citation of the original publisher and author. The - publisher and author's names shall appear on all outer surfaces of - the book. On all outer surfaces of the book the original publisher's - name shall be as large as the title of the work and cited as - possessive with respect to the title. - -
-
- II. COPYRIGHT - - - The copyright to each Open Publication is owned by its author(s) or - designee. - -
-
- III. SCOPE OF LICENSE - - - The following license terms apply to all Open Publication works, - unless otherwise explicitly stated in the document. - - - - Mere aggregation of Open Publication works or a portion of an Open - Publication work with other works or programs on the same media - shall not cause this license to apply to those other works. The - aggregate work shall contain a notice specifying the inclusion of - the Open Publication material and appropriate copyright notice. - - - - SEVERABILITY. If any part of this license is found to be - unenforceable in any jurisdiction, the remaining portions of the - license remain in force. - - - - NO WARRANTY. Open Publication works are licensed and provided "as - is" without warranty of any kind, express or implied, including, but - not limited to, the implied warranties of merchantability and - fitness for a particular purpose or a warranty of non-infringement. - -
-
- IV. REQUIREMENTS ON MODIFIED WORKS - - - All modified versions of documents covered by this license, - including translations, anthologies, compilations and partial - documents, must meet the following requirements: - - - - - - - The modified version must be labeled as such. - - - - - The person making the modifications must be identified and the - modifications dated. - - - - - Acknowledgement of the original author and publisher if - applicable must be retained according to normal academic - citation practices. - - - - - The location of the original unmodified document must be - identified. - - - - - The original author's (or authors') name(s) may not be used - to assert or imply endorsement of the resulting document - without the original author's (or authors') permission. - - - - -
-
- V. GOOD-PRACTICE RECOMMENDATIONS - - - In addition to the requirements of this license, it is requested - from and strongly recommended of redistributors that: - - - - - - - If you are distributing Open Publication works on hardcopy or - CD-ROM, you provide email notification to the authors of your - intent to redistribute at least thirty days before your - manuscript or media freeze, to give the authors time to - provide updated documents. This notification should describe - modifications, if any, made to the document. - - - - - All substantive modifications (including deletions) be either - clearly marked up in the document or else described in an - attachment to the document. - - - - - Finally, while it is not mandatory under this license, it is - considered good form to offer a free copy of any hardcopy and - CD-ROM expression of an Open Publication-licensed work to its - author(s). - - - - -
-
- VI. LICENSE OPTIONS - - - The author(s) and/or publisher of an Open Publication-licensed - document may elect certain options by appending language to the - reference to or copy of the license. These options are considered - part of the license instance and must be included with the license - (or its incorporation by reference) in derived works. - - - - A. To prohibit distribution of substantively modified versions - without the explicit permission of the author(s). "Substantive - modification" is defined as a change to the semantic content of the - document, and excludes mere changes in format or typographical - corrections. - - - - To accomplish this, add the phrase `Distribution of substantively - modified versions of this document is prohibited without the - explicit permission of the copyright holder.' to the license - reference or copy. - - - - B. To prohibit any publication of this work or derivative works in - whole or in part in standard (paper) book form for commercial - purposes is prohibited unless prior permission is obtained from the - copyright holder. - - - - To accomplish this, add the phrase 'Distribution of the work or - derivative of the work in any standard (paper) book form is - prohibited unless prior permission is obtained from the copyright - holder.' to the license reference or copy. - -
+ + + + +
+ + Permission is granted to copy, distribute, and/or modify this + document under the terms of the Open Publication Licence, Version + 1.0 or any later version. The terms of the OPL are set out below. + +
+
+ REQUIREMENTS ON BOTH UNMODIFIED AND MODIFIED VERSIONS + + + The Open Publication works may be reproduced and distributed in + whole or in part, in any medium physical or electronic, provided + that the terms of this license are adhered to, and that this + license or an incorporation of it by reference (with any options + elected by the author(s) and/or publisher) is displayed in the + reproduction. + + + + Proper form for an incorporation by reference is as follows: + + + + Copyright (c) <year> by <author's name or designee>. + This material may be distributed only subject to the terms and + conditions set forth in the Open Publication License, vX.Y or + later (the latest version is presently available at + + + + + The reference must be immediately followed with any options + elected by the author(s) and/or publisher of the document (see + section VI). Commercial redistribution of Open + Publication-licensed material is permitted. Any publication in + standard (paper) book form shall require the citation of the + original publisher and author. The publisher and author's names + shall appear on all outer surfaces of the book. On all outer + surfaces of the book the original publisher's name shall be as + large as the title of the work and cited as possessive with + respect to the title. + +
+
+ COPYRIGHT + + + The copyright to each Open Publication is owned by its author(s) + or designee. + +
+
+ SCOPE OF LICENSE + + + The following license terms apply to all Open Publication works, + unless otherwise explicitly stated in the document. + + + + Mere aggregation of Open Publication works or a portion of an Open + Publication work with other works or programs on the same media + shall not cause this license to apply to those other works. The + aggregate work shall contain a notice specifying the inclusion of + the Open Publication material and appropriate copyright notice. + + + + SEVERABILITY. If any part of this license is found to be + unenforceable in any jurisdiction, the remaining portions of the + license remain in force. + + + + NO WARRANTY. Open Publication works are licensed and provided "as + is" without warranty of any kind, express or implied, including, + but not limited to, the implied warranties of merchantability and + fitness for a particular purpose or a warranty of + non-infringement. + +
+
+ REQUIREMENTS ON MODIFIED WORKS + + + All modified versions of documents covered by this license, + including translations, anthologies, compilations and partial + documents, must meet the following requirements: + + + + + + + The modified version must be labeled as such. + + + + + The person making the modifications must be identified and + the modifications dated. + + + + + Acknowledgement of the original author and publisher if + applicable must be retained according to normal academic + citation practices. + + + + + The location of the original unmodified document must be + identified. + + + + + The original author's (or authors') name(s) may not be used + to assert or imply endorsement of the resulting document + without the original author's (or authors') permission. + + + + +
+
+ GOOD-PRACTICE RECOMMENDATIONS + + + In addition to the requirements of this license, it is requested + from and strongly recommended of redistributors that: + + + + + + + If you are distributing Open Publication works on hardcopy + or CD-ROM, you provide email notification to the authors of + your intent to redistribute at least thirty days before your + manuscript or media freeze, to give the authors time to + provide updated documents. This notification should describe + modifications, if any, made to the document. + + + + + All substantive modifications (including deletions) be + either clearly marked up in the document or else described + in an attachment to the document. + + + + + Finally, while it is not mandatory under this license, it is + considered good form to offer a free copy of any hardcopy + and CD-ROM expression of an Open Publication-licensed work + to its author(s). + + + + +
+
+ LICENSE OPTIONS + + + The author(s) and/or publisher of an Open Publication-licensed + document may elect certain options by appending language to the + reference to or copy of the license. These options are considered + part of the license instance and must be included with the license + (or its incorporation by reference) in derived works. + + + + A. To prohibit distribution of substantively modified versions + without the explicit permission of the author(s). "Substantive + modification" is defined as a change to the semantic content of + the document, and excludes mere changes in format or typographical + corrections. + + + + To accomplish this, add the phrase `Distribution of substantively + modified versions of this document is prohibited without the + explicit permission of the copyright holder.' to the license + reference or copy. + + + + B. To prohibit any publication of this work or derivative works in + whole or in part in standard (paper) book form for commercial + purposes is prohibited unless prior permission is obtained from + the copyright holder. + + + + To accomplish this, add the phrase 'Distribution of the work or + derivative of the work in any standard (paper) book form is + prohibited unless prior permission is obtained from the copyright + holder.' to the license reference or copy. + +
+ From fedora-docs-commits at redhat.com Tue Oct 18 23:10:32 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Tue, 18 Oct 2005 19:10:32 -0400 Subject: rpm-guide rpm-guide-en.xml,1.1,1.2 Message-ID: <200510182310.j9INAWBl005056@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv5022 Modified Files: rpm-guide-en.xml Log Message: Modified to use OPL file from docs-common as legal notice. Index: rpm-guide-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- rpm-guide-en.xml 4 Oct 2005 01:50:50 -0000 1.1 +++ rpm-guide-en.xml 18 Oct 2005 23:10:29 -0000 1.2 @@ -8,12 +8,9 @@ - - - @@ -60,7 +57,7 @@ Eric - &LEGALNOTICE; + &LEGALNOTICE-OPL-CONTENT; 0.1 From fedora-docs-commits at redhat.com Thu Oct 20 20:00:47 2005 From: fedora-docs-commits at redhat.com (Karsten Wade (kwade)) Date: Thu, 20 Oct 2005 16:00:47 -0400 Subject: owners owners.list,1.8,1.9 Message-ID: <200510202000.j9KK0lLv016069@cvs-int.fedora.redhat.com> Author: kwade Update of /cvs/docs/owners In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16050/owners Modified Files: owners.list Log Message: Adding in the list of formal Fedora websites, perhaps to grow, perhaps not. Index: owners.list =================================================================== RCS file: /cvs/docs/owners/owners.list,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- owners.list 18 Oct 2005 07:51:38 -0000 1.8 +++ owners.list 20 Oct 2005 20:00:45 -0000 1.9 @@ -41,7 +41,7 @@ # Content delivery and infrastructure components # -Fedora Documentation|fedora-websites|Problems and requests for all formal Fedora Project websites, such as fedoraproject.org.|nman64 at n-man.com|kwade at redhat.com| +Fedora Documentation|fedora-websites|Problems and requests for all formal Fedora Project websites. This list is currently: fedoraproject.org and fedora.redhat.com.|nman64 at n-man.com|kwade at redhat.com| # # Specific FDP document components From fedora-docs-commits at redhat.com Fri Oct 21 00:20:34 2005 From: fedora-docs-commits at redhat.com (Paul Nasrat (pnasrat)) Date: Thu, 20 Oct 2005 20:20:34 -0400 Subject: rpm-guide rpm-guide-programming-python-en.xml,1.1,1.2 Message-ID: <200510210020.j9L0KY61023928@cvs-int.fedora.redhat.com> Author: pnasrat Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv23909 Modified Files: rpm-guide-programming-python-en.xml Log Message: Remove spurious paragraph Index: rpm-guide-programming-python-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-programming-python-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- rpm-guide-programming-python-en.xml 4 Oct 2005 01:58:53 -0000 1.1 +++ rpm-guide-programming-python-en.xml 21 Oct 2005 00:20:31 -0000 1.2 @@ -35,10 +35,6 @@ *Installing packages programmatically - - P - - Setting Up a Python Development Environment From fedora-docs-commits at redhat.com Fri Oct 21 23:30:43 2005 From: fedora-docs-commits at redhat.com (Tommy Reynolds (jtr)) Date: Fri, 21 Oct 2005 19:30:43 -0400 Subject: docs-common/xsl main-html.xsl,1.7,1.8 Message-ID: <200510212330.j9LNUiSk002090@cvs-int.fedora.redhat.com> Author: jtr Update of /cvs/docs/docs-common/xsl In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv2068 Modified Files: main-html.xsl Log Message: Removed extraneous setting because the stylesheet fails to validate if a more modern, non-xsltproc parser, such as saxon, is used. Index: main-html.xsl =================================================================== RCS file: /cvs/docs/docs-common/xsl/main-html.xsl,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- main-html.xsl 4 Sep 2005 14:50:25 -0000 1.7 +++ main-html.xsl 21 Oct 2005 23:30:40 -0000 1.8 @@ -145,8 +145,4 @@ 1 --> - - - - From fedora-docs-commits at redhat.com Mon Oct 24 11:36:51 2005 From: fedora-docs-commits at redhat.com (Paul W. Frields (pfrields)) Date: Mon, 24 Oct 2005 07:36:51 -0400 Subject: jargon-buster jargon-buster-en.xml,1.11,1.12 Message-ID: <200510241136.j9OBaprC012509@cvs-int.fedora.redhat.com> Author: pfrields Update of /cvs/docs/jargon-buster In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv12490 Modified Files: jargon-buster-en.xml Log Message: Fix spelling of Linus' name (#171596), bump to 1.9.4.1 Index: jargon-buster-en.xml =================================================================== RCS file: /cvs/docs/jargon-buster/jargon-buster-en.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- jargon-buster-en.xml 5 Oct 2005 12:00:46 -0000 1.11 +++ jargon-buster-en.xml 24 Oct 2005 11:36:48 -0000 1.12 @@ -4,7 +4,7 @@ %FEDORA-ENTITIES-EN; - + ]> @@ -190,6 +190,16 @@ + + 1.9.4.1 + 24 Oct 2005 + PaulWFrields + + + Spelling correction (#171596). + + + @@ -747,7 +757,7 @@ A kernel is the core of an operating system, responsible for managing memory and conducting hardware operations. The Linux kernel used in &FED; is free and open source software, - originally written by Linux Torvalds. Many computer + originally written by Linus Torvalds. Many computer scientists and programmers from around the world now contribute to its development. From fedora-docs-commits at redhat.com Mon Oct 24 13:05:16 2005 From: fedora-docs-commits at redhat.com (Karsten Wade (kwade)) Date: Mon, 24 Oct 2005 09:05:16 -0400 Subject: release-notes/figs - New directory Message-ID: <200510241305.j9OD5Gqh015965@cvs-int.fedora.redhat.com> Author: kwade Update of /cvs/docs/release-notes/figs In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv15950/figs Log Message: Directory /cvs/docs/release-notes/figs added to the repository From fedora-docs-commits at redhat.com Mon Oct 24 13:05:20 2005 From: fedora-docs-commits at redhat.com (Karsten Wade (kwade)) Date: Mon, 24 Oct 2005 09:05:20 -0400 Subject: release-notes/css - New directory Message-ID: <200510241305.j9OD5Kwe015980@cvs-int.fedora.redhat.com> Author: kwade Update of /cvs/docs/release-notes/css In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv15950/css Log Message: Directory /cvs/docs/release-notes/css added to the repository From fedora-docs-commits at redhat.com Mon Oct 24 13:06:12 2005 From: fedora-docs-commits at redhat.com (Karsten Wade (kwade)) Date: Mon, 24 Oct 2005 09:06:12 -0400 Subject: release-notes/img - New directory Message-ID: <200510241306.j9OD6CZb015994@cvs-int.fedora.redhat.com> Author: kwade Update of /cvs/docs/release-notes/img In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv15950/img Log Message: Directory /cvs/docs/release-notes/img added to the repository From fedora-docs-commits at redhat.com Mon Oct 24 13:13:37 2005 From: fedora-docs-commits at redhat.com (Karsten Wade (kwade)) Date: Mon, 24 Oct 2005 09:13:37 -0400 Subject: release-notes Makefile, NONE, 1.1 README-en.xml, NONE, 1.1 RELEASE-NOTES-en.xml, NONE, 1.1 RELEASE-NOTES-master-en.xml, NONE, 1.1 announcement-release.txt, NONE, 1.1 daemons.xml, NONE, 1.1 database-servers.xml, NONE, 1.1 desktop.xml, NONE, 1.1 development-tools.xml, NONE, 1.1 eula.py, NONE, 1.1 eula.txt, NONE, 1.1 fedora-devel.repo, NONE, 1.1 fedora-release.spec, NONE, 1.1 fedora-updates-testing.repo, NONE, 1.1 fedora-updates.repo, NONE, 1.1 fedora.css, NONE, 1.1 fedora.repo, NONE, 1.1 feedback.xml, NONE, 1.1 file-servers.xml, NONE, 1.1 file-systems.xml, NONE, 1.1 hardware-reqs.xml, NONE, 1.1 install-notes.xml, NONE, 1.1 intro.xml, NONE, 1.1 java-package.xml, NONE, 1.1 kernel.xml, NONE, 1.1 main.xsl, NONE, 1.1 misc-server.xml, NONE, 1.1 multimedia.xml, NONE, 1.1 networking.xml, NONE, 1.1 overview.xml, NONE, 1.1 package-movement.xml, NONE, 1.1 package-notes.xml, NONE, 1.1 printing.xml, NONE, 1.1 project-overview.xml, NONE, 1.1 readmes.xsl, NONE, 1.1 samba.xml, NONE, 1.1 security.xml, NONE, 1.1 server-tools.xml, NONE, 1.1 sources, NONE, 1.1 spl! ash.xml,NONE,1.1 web-servers.xml,NONE,1.1 xorg.xml,NONE,1.1 Message-ID: <200510241313.j9ODDbDM016130@cvs-int.fedora.redhat.com> Author: kwade Update of /cvs/docs/release-notes In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16016 Added Files: Makefile README-en.xml RELEASE-NOTES-en.xml RELEASE-NOTES-master-en.xml announcement-release.txt daemons.xml database-servers.xml desktop.xml development-tools.xml eula.py eula.txt fedora-devel.repo fedora-release.spec fedora-updates-testing.repo fedora-updates.repo fedora.css fedora.repo feedback.xml file-servers.xml file-systems.xml hardware-reqs.xml install-notes.xml intro.xml java-package.xml kernel.xml main.xsl misc-server.xml multimedia.xml networking.xml overview.xml package-movement.xml package-notes.xml printing.xml project-overview.xml readmes.xsl samba.xml security.xml server-tools.xml sources splash.xml web-servers.xml xorg.xml Log Message: EPOCH. Moving all essential release notes XML and related files to the root level for the module. This is done as part of FC5 test1 relnote construction. This is an epoch event because previously versioning was done with unique directories for each release. From this moment forward we are going to use CVS tagging and branching with files all within this directory. Sub-directories are therefore archive directories. It is important to note that this check-in perfectly mirrors the state of FC4 latest release notes, therefore this first check-in shall be tagged as FC4 so that we can return to this point for building FC4 notes in the future. *docs* --- NEW FILE Makefile --- LANG = en DOCS_SETUP_PATH= ../../docs-common XSLPDF = $(DOCS_SETUP_PATH)/xsl/main-pdf.xsl XSLHTML = $(DOCS_SETUP_PATH)/xsl/main-html-nochunks-relnotes.xsl XSLPDFCOMMONS = ${XSLPDF} XSLHTMLCOMMONS = ${XSLHTML} XMLCOMMONSPATH=${DOCS_SETUP_PATH}/common XMLCOMMONS=${XMLCOMMONSPATH}/cvs-en.xml \ ${XMLCOMMONSPATH}/draftnotice-en.xml \ ${XMLCOMMONSPATH}/fedora-entities-en.ent \ ${XMLCOMMONSPATH}/fedora-entities-en.xml \ ${XMLCOMMONSPATH}/legacynotice-en.xml \ ${XMLCOMMONSPATH}/legalnotice-en.xml \ ${XMLCOMMONSPATH}/obsoletenotice-en.xml .SUFFIXES: .SUFFIXES: .html .pdf .xml all: README-${LANG}.html \ RELEASE-NOTES-${LANG}.html \ RELEASE-NOTES-${LANG}.txt \ README-${LANG}.txt #README-${LANG}.pdf RELEASE-NOTES-${LANG}.pdf %.pdf: %.xml xmlto pdf -x ${XSLPDF} $< %.html: %.xml ${RM} -r ${@:.html=} xmlto html -x ${XSLHTML} -o ${@:.html=} $< mkdir -p ${@:.html=}/stylesheet-images mkdir -p ${@:.html=}/figs cp $(DOCS_SETUP_PATH)/stylesheet-images/*.png ${@:.html=}/stylesheet-images cp ./figs/*.png ${@:.html=}/figs cp $(DOCS_SETUP_PATH)/css/fedora.css ${@:.html=} mv ${@:.html=}/${@:.html=.proc} ${@:.html=}/$@ ln -sf ${@:.html=}/$@ $@ %.txt: %.xml xmlto txt $< # mv $@ RELEASE-NOTES-${LANG} # FIXME eula.txt: eula.py # FIXME python -c "import py_compile; py_compile.compile('eula.py')" # Note: keep "RELEASE-NOTES-en.xml" first, for now. RNFILES=RELEASE-NOTES-en.xml daemons.xml database-servers.xml \ desktop.xml development-tools.xml feedback.xml file-servers.xml \ file-systems.xml hardware-reqs.xml install-notes.xml intro.xml \ java-package.xml kernel.xml misc-server.xml multimedia.xml \ networking.xml overview.xml package-movement.xml \ package-notes.xml printing.xml project-overview.xml samba.xml \ security.xml server-tools.xml splash.xml web-servers.xml \ xorg.xml # README-${LANG}.pdf: README-en.xml # README-${LANG}.html: README-en.xml RELEASE-NOTES-${LANG}.pdf: ${RNFILES} ${XMLCOMMONS} ${XSLPDFCOMMONS} RELEASE-NOTES-${LANG}.html: ${RNFILES} ${XMLCOMMONS} ${XSLHTMLCOMMONS} RELEASE-NOTES-${LANG}.txt: ${RNFILES} ${XMLCOMMONS} clean: ${RM} ChangeLog ChangeLog.xml distclean clobber: clean ${RM} ChangeLog-${LANG}.html ChangeLog.txt ${RM} -r README-${LANG}.pdf README-${LANG}.html README-${LANG}.txt ${RM} -r RELEASE-NOTES-${LANG}.pdf RELEASE-NOTES-${LANG}.html \ RELEASE-NOTES-${LANG} RELEASE-NOTES-${LANG}.txt # If you have the "cvs2cl" package installed, then you can make # fancy HTML ChangeLogs ChangeLogs: ${RM} ChangeLog* ${MAKE} ChangeLog.txt ${MAKE} ChangeLog-${LANG}.html ChangeLog.txt: LANG=C cvs2cl -f ChangeLog.txt ChangeLog.xml: LANG=C cvs2cl --xml --xml-encoding UTF-8 -f ChangeLog.xml ChangeLog-${LANG}.html: ChangeLog.xml xsltproc -o $@ /usr/share/xml/cvs2cl/cl2html.xslt $< --- NEW FILE README-en.xml --- ]>
&DISTRO; &DISTROVER; README 2005 &FORMAL-RHI; The contents of this CD-ROM are Copyright © 2005 &PROJ; and others. Refer to the End User License Agreement and individual copyright notices in each source package for distribution terms. &NAME;, &RH;, &RH; Network, the &RH; "Shadow Man" logo, RPM, Maximum RPM, the RPM logo, Linux Library, PowerTools, Linux Undercover, RHmember, RHmember More, Rough Cuts, Rawhide and all &RH;-based trademarks and logos are trademarks or registered trademarks of &FORMAL-RHI; in the United States and other countries. Linux is a registered trademark of Linus Torvalds. Motif and UNIX are registered trademarks of The Open Group. Intel and Pentium are registered trademarks of Intel Corporation. Itanium and Celeron are trademarks of Intel Corporation. AMD, AMD Athlon, AMD Duron, and AMD K6 are trademarks of Advanced Micro Devices, Inc. Windows is a registered trademark of Microsoft Corporation. SSH and Secure Shell are trademarks of SSH Communications Security, Inc. FireWire is a trademark of Apple Computer Corporation. All other trademarks and copyrights referred to are the property of their respective owners. The GPG fingerprint of the "Fedora Project <fedora at redhat.com>" key is: CA B4 4B 99 6F 27 74 4E 86 12 7C DF B4 42 69 D0 4F 2A 6F D2
DIRECTORY ORGANIZATION &DISTRO; is delivered on multiple CD-ROMs consisting of installation CD-ROMs and source code CD-ROMs. The first installation CD-ROM can be directly booted into the installation on most modern systems, and contains the following directory structure (where /mnt/cdrom is the mount point of the CD-ROM): /mnt/cdrom |----> Fedora | |----> RPMS -- binary packages | `----> base -- information on this release of Fedora | Core used by the installation process |----> images -- boot and driver disk images |----> isolinux -- files necessary to boot from CD-ROM |----> README -- this file |----> RELEASE-NOTES -- the latest information about this release | of Fedora Core `----> RPM-GPG-KEY -- GPG signature for packages from Red Hat The remaining Installation CD-ROMs are similar to Installation CD-ROM 1, except that only the Fedora subdirectory is present. The directory layout of each source code CD-ROM is as follows: /mnt/cdrom |----> SRPMS -- source packages `----> RPM-GPG-KEY -- GPG signature for packages from Red Hat If you are setting up an installation tree for NFS, FTP, or HTTP installations, you need to copy the RELEASE-NOTES files and all files from the Fedora directory on discs 1-3. On Linux and Unix systems, the following process will properly configure the /target/directory on your server (repeat for each disc): Insert disc mount /mnt/cdrom cp -a /mnt/cdrom/Fedora /target/directory cp /mnt/cdrom/RELEASE-NOTES* /target/directory (Do this only for disc 1) umount /mnt/cdrom
INSTALLING Many computers can now automatically boot from CD-ROMs. If you have such a machine (and it is properly configured) you can boot the &DISTRO; CD-ROM directly. After booting, the &DISTRO; installation program will start, and you will be able to install your system from the CD-ROM. The images/ directory contains the file boot.iso. This file is an ISO image that can be used to boot the &DISTRO; installation program. It is a handy way to start network-based installations without having to use multiple diskettes. To use boot.iso, your computer must be able to boot from its CD-ROM drive, and its BIOS settings must be configured to do so. You must then burn boot.iso onto a recordable/rewriteable CD-ROM. Another image file contained in the images/ directory is diskboot.img. This file is designed for use with USB pen drives (or other bootable media with a capacity larger than a diskette drive). Use the dd command to write the image. Note The ability to use this image file with a USB pen drive depends on the ability of your system's BIOS to boot from a USB device.
GETTING HELP For those that have web access, see http://fedora.redhat.com. In particular, access to &PROJ; mailing lists can be found at: https://listman.redhat.com/mailman/listinfo/
EXPORT CONTROL The communication or transfer of any information received with this product may be subject to specific government export approval. User shall adhere to all applicable laws, regulations and rules relating to the export or re-export of technical data or products to any proscribed country listed in such applicable laws, regulations and rules unless properly authorized. The obligations under this paragraph shall survive in perpetuity.
***** Error reading new file: [Errno 2] No such file or directory: 'RELEASE-NOTES-en.xml' --- NEW FILE RELEASE-NOTES-master-en.xml --- ]>
&PROD; @VARIANTUPPER@ &PRODVER; Release Notes 2003 &FORMAL-RHI; Overview The following topics are covered in these release notes: Booting Anaconda Parameter file notes Installation-related notes Notes on input methods General notes Kernel notes Booting Anaconda This section describes the process necessary to boot Anaconda, the &PROD; installation program. For the IBM eServer pSeries: The first CD-ROM is bootable, and can be used to start the installation process. If a CD-ROM-based installation is not desired (for example, if you want to install &PROD; &PRODVER; over a network connection), a CD-ROM image file containing only those files required to start the installation process is also available as boot.iso in the images/ directory on the first CD-ROM. A network boot image (named netboot.img) is available, and is located in the images/ directory on Installation CD 1. Consult the documentation that came with your system for instructions on setting up network boot. Kernel command line arguments (such as anaconda options) must be passed from the Open Firmware prompt. For example, if there is a devalias named network for the device that is configured for network booting, the following command line would load a driver disk from an HTTP server: boot network dd=http://server.example.com/path/to/driverdisk.img Additional documentation for configuring netboot on pSeries can be found here: http://people.redhat.com/msw/mirror/penguinppc.org/~hollis/linux/rs6k-netboot.shtml For the IBM eServer iSeries: You must direct OS/400 to boot the stream file ppc/iSeries/boot.img, which is located on the first CD-ROM. You can either point directly at the CD-ROM or copy the file to a location in IFS. When the installation is complete, it will boot from side C, but this will only work until you vary off your LPAR. After varying off your LPAR, you must change your IPL source to side B to continue booting &PROD;. You must download the kernel.img and initrd.img files from the images/ directory into CMS. You can then use these with a parameter file (described in the following section) to start your installation. Once the Linux kernel has booted, use ssh to access your VM and start the installation process. When the installation finishes, you must use a command similar to #cp ipl 0200 to bootstrap (or IPL) the Linux installation on the DASD at 0200. Parameter File Notes The IBM S/390 and IBM eServer zSeries architectures use a special parameter file to set up networking before the installation program (anaconda) can be started. This section describes the contents of the parameter file. The parameter file should contain no more than 80 characters per line. The VM reader has a limit of 11 lines for the parameter file (for a total of 880 characters). The DASD and the tape IPL have a limit of 896 characters. The following parameters are required, and should always be present: DASD=<dasd-list> Where <dasd-list> represents the list of DASD devices to be used by &PROD;. The list can consist of one or more DASD numbers separated by commas, and can also contain ranges, which are specified by two DASD numbers separated by a hyphen. Both constructs can be combined in a single list, as in the following example: DASD=10A8,10A9,10AA,10A3-10A6 NOTE: Although autoprobing for DASDs is done if this parameter is omitted, &RH; highly recommend including the DASD= parameter as the device numbers (and therefore the device names) can vary when new DASD is added to the &PROD; guest. This can result in an unusable system. root=<file-system> Where <file-system> represents the device on which the root file system can be found. For for installation purposes, it should be set to /dev/ram0, which is the ramdisk containing the &PROD; installation program. The following parameters are required to set up networking: CHANDEV=<device>,<input>,<output> where: · <device> is the type of device (for example, ctc0, escon0, or lcs0) · <input> is the input port for this device · <output> is the output port for this device For example: CHANDEV=ctc0,0x600,0x601 CHANDEV=escon0,0x605,0x608 To force a specific CTC protocol, additional parameters can be added. For example: CHANDEV=ctc0,0x600,0x601,0,<n> where <n> is one of the following: · 0 for compatibility mode (used with non-Linux peers other than S/390 and zSeries operating systems) · 1 for extended mode · 2 for CTC-based tty (only supported on Linux-to-Linux connections) · 3 for compatibility mode with S/390 and zSeries operating systems IUCV=<userid> Where <userid> represents the ID of the guest machines you want to connect to. Note that the ID must be written in capital letters. For example, an IUCV connection to the VM TCP/IP service machine would be written as: IUCV=TCPIP The following parameters are optional: HOSTNAME=<string> where <string> is the hostname of the newly-installed Linux guest. NETTYPE=<type> where <type> must be one of the following: ctc, escon, tr, hsi, iucv, or eth. IPADDR=<IP> where <IP> is the IP address of the new Linux guest. NETWORK=<network> where <network> is the address of your network. NETMASK=<netmask> where <netmask> is the netmask. BROADCAST=<broadcast> where <broadcast> is the broadcast address. GATEWAY=<gw> where <gw> is either the gateway-IP for your eth device or the IP address of the ctc/escon/iucv point-to-point partner. MTU=<mtu> where <mtu> is the Maximum Transmission Unit (MTU) for this connection. DNS=<server1>:<server2>:…:<serverN> where <server1>:<server2>:…:<serverN> is a list of DNS servers, separated by colons. For example: DNS=10.0.0.1:10.0.0.2 SEARCHDNS=<domain1>:<domain2>:…:<domainN> where <domain1>:<domain2>:…:<domainN> is a list of the search domains, separated by colons. For example: SEARCHDNS=example.com:example.org The following parameter for installations using a qeth device is optional: QETHPARM= Use this option to specify additional parameters for your QETH device (for CHANDEV) such as: add_parms,0x10,{lo_devno,hi_devno},portname:<port_name> The following parameter for kickstart installation is optional: RUNKS=<value> Where <value> is 1 if you want to run the installation program in non-interactive mode in the 3270 terminal, or 0 otherwise. NOTE: Make sure that your kickstart file contains all required parameters before you use this option. Installation-Related Notes This section describes issues related to the &PROD; installation program Anaconda. The sequence for processing CD-ROMs has changed for &PROD; &PRODVER;. The first CD-ROM is required when booting the installation program, and again after subsequent CD-ROMs have been processed. The &PROD; installation program has the ability to test the integrity of the installation media. It works with the CD, hard drive ISO, and NFS ISO installation methods. &RH; recommends that you test all installation media before starting the installation process, and before reporting any installation-related bugs (many of the bugs reported are actually due to improperly-burned CDs). To use this test, type linux mediacheck at the boot: prompt. The Object-code-only (OCO) driver necessary to support the IBM 3590 Tape Drive on the IBM S/390(R) and IBM eServer zSeries(R) architectures is available for download from IBM here: http://www10.software.ibm.com/developerworks/opensource/linux390/special_oco_rh_2.4.shtml NOTE: You must verify that the driver you download is the correct one for the version of the kernel running on your system. A new storage option is available on the s390 and zSeries architectures: a SCSI subsystem. To that end, generic SCSI support is enabled and a driver (known as zfcp) is supplied. The generic SCSI subsystem on &PROD; &PRODVER; does not use the REPORT LUNs command at this time; therefore use small LUN numbers for virtual volumes. In addition, the following line must be supplied in /etc/modules.conf: options scsi_mod max_scsi_luns=<NNN> (Where <NNN> should be a number larger than the largest LUN number used.) NOTE: Larger values slow the bootstrapping process somewhat. &PROD; &PRODVER; includes a new kernel known as the hugemem kernel. This kernel supports a 4GB per process user space (versus 3GB for the other kernels), and a 4GB direct kernel space. Using this kernel allows &PROD; to run on systems with up to 64GB of main memory. The hugemem kernel is required in order to use all the memory in system configurations containing more than 16GB of memory. The hugemem kernel can also benefit configurations running with less memory (if running an application that could benefit from the larger per process user space, for example.) To remind you of this issue, the &PROD; &PRODVER; kernel displays a message at boot time if your system configuration contains more than 16GB of memory. After the system has booted, the following command can be used to see if your system displayed the message: dmesg | less NOTE: To provide a 4GB address space for both kernel and user space, the kernel must maintain two separate virtual memory address mappings. This introduces overhead when transferring from user to kernel space; for example, in the case of system calls and interrupts. The impact of this overhead on overall performance is highly application dependent. Also note that, because some drivers were not originally written to work well in large-memory environments, &RH; only supports a validated subset of drivers when the hugemem kernel is used. Drivers that have been validated by &RH; for use with the hugemem kernel are contained in the kernel-hugemem package. Drivers that have not been validated, but are still provided, are available in the kernel-hugemem-unsupported RPM. To see the list of drivers in these RPMs, use the following command: rpm -qlp <kernel-rpm> (Where < kernel-rpm> is the complete filename of the appropriate hugemem RPM. Note that these RPMs can be found on CD-ROM #2, in the RedHat/RPMS/ directory.) Should you decide that the hugemem kernel's additional overhead and the subset of available drivers present no problem for your hardware configuration and system environment, and you wish to use the hugemem kernel, you must first install it. To install the hugemem kernel, enter the following command while logged in as root: rpm -ivh <kernel-rpm> (Where <kernel-rpm> is the name of the hugemem kernel RPM file — kernel-hugemem-2.4.21-3.EL.i686.rpm, for example.) After the installation is complete, reboot your system, making sure to select the newly-installed hugemem kernel. After testing your system for proper operation while running the hugemem kernel, you should modify the /boot/grub/grub.conf file so that the hugemem kernel is booted by default. &PROD; &PRODVER; can be installed on the IBM eServer xSeries 440 and 445. However, the installation process supports configurations containing no more than one chassis, and no attached RXE-100 Remote Expansion Enclosures. If your system configuration does not conform to these requirements, you can remove any additional chassis and/or RXE-100s, and then perform the installation. Once the installation is complete, the chassis and/or RXE-100s can then be re-installed, and will operate normally under &PROD;. Support for some Input/Output Processors/Adapters (IOP/IOA) present in some iSeries and pSeries systems require the use of the IBMSIS driver. This driver can be found on the &PROD; &PRODVER; Extras CD, and can be loaded as driver media when the &PROD; installation process is started. Loading the IBMSIS driver via CD-ROM using a non-IDE CD-ROM drive (including the iSeries virtual CD-ROM drive) is possible by adding the following command to the boot command line: dd=cdrom You will then be prompted if you have any driver media for additional drivers after all drivers included on the CD-ROM are loaded. Note that this is in addition to the other methods of using driver media as described in the &PROD; &PRODVER; Installation Guide for the IBM eServer iSeries and IBM eServer pSeries Architectures. After installation, IBMSIS users should install the ibmsis and ibmsis-utils packages from the &PROD; Extras CD. After an upgrade to a new version of the kernel, the IBMSIS driver must be rebuilt and installed. The ibmsistool program (provided in the ibmsis package on the &PROD; &PRODVER; Extras CD) largely automates this process. The kernel-source package that corresponds to the new kernel must be installed, as it provides the headers needed to build IBMSIS. For example, after installing the 2.4.21-3.EL kernel and corresponding kernel-source packages, the following command would update the IBMSIS driver: /usr/sbin/ibmsistool -v 2.4.21-3.EL build install &PROD; &PRODVER; now includes support for Logical Volume Management (LVM). LVM is a means of allocating disk space into one or more logical volumes, which can then be used to implement easily-resizable file systems. While most present-day computers are able to start the installation process by booting directly from the first &PROD; distribution CD, some hardware configurations require the use of a boot diskette. If your hardware requires a boot diskette, you should be aware of the following change. &PROD; &PRODVER; uses a different boot diskette layout than previous releases of &PROD;. There is now a single boot diskette image file (bootdisk.img) that is used to boot all systems requiring a boot diskette. If you are performing anything other than an installation from an IDE or USB device, you will be asked to insert a driver diskette created from one of the following image files: · drvnet.img — For network installations · drvblock.img — For SCSI installations · pcmciadd.img — For PCMCIA installations As with previous releases of &PROD;, these image files can be found in the images/ directory on the first installation CD. Due to the page-oriented nature of the 3270-style console, output to /dev/console can fill the screen. If the screen is filled, the &PROD; environment stops operating until the screen is cleared. The screen can be cleared using one of two different methods: · By issuing the keystrokes necessary to clear the screen (For example, AltC for the x3270 terminal emulator, and CtrlC for the c3270 terminal emulator.) · By waiting for the screen to be automatically cleared. The default wait time is 60 seconds; however, this can be changed by using the following command: #cp term more <alarm-time> <clear-time> Where <alarm-time> represents the number of seconds between the time the screen fills and the time the terminal alarm should be sounded, and <clear-time> is the number of seconds between the time the terminal alarm is sounded and the screen is automatically cleared. Both the <alarm-time> and <clear-time> parameters must be numbers between 0 and 255. NOTE: This aspect of the 3270-style console is most likely to be an issue whenever a large amount of output is sent to /dev/console. Therefore, the console's screen is most likely to fill at the following times: · During the &PROD; installation process · When &PROD; is booted · syslog messages are sent to the console Text mode installations using a serial terminal work best when the terminal supports UTF-8. Under UNIX and Linux, Kermit supports UTF-8. For Windows, Kermit '95 works well. Non-UTF-8 capable terminals will work as long as only English is used during installation. An enhanced serial display can be used by passing "utf8" as a boot-time option to the installation program. For example: linux console=ttyS0 utf8 The firewall configuration screen in the &PROD; installation program has been simplified. The previous "High", "Medium", and "No firewall" settings have been replaced by a more straightforward on/off-style control. In addition, the default firewall configuration is now stateful, making it more secure. The new design also makes it possible for users of NIS authentication, NFS, and DNS to deploy a firewall with no additional customization required (although customization by specifying port and protocol is still possible). NOTE: This change also applies to the Security Level Configuration Tool (redhat-config-securitylevel). Installation via VNC is now supported. To initiate a VNC-based installation, pass vnc as a boot-time option. If necessary, a password can be set by adding "vncpassword=<password>" to the boot-time options. The VNC display will be "<host>:1", where <host> is the hostname or IP address of the system installing &PROD;. It is also possible for the &PROD; installation program to initiate a connection to a listening VNC client. This is done by using the vncconnect boot-time option: linux vnc vncconnect=<client>[:<port>] (Where <client> is the hostname or IP address of the system running the listening VNC client, and <port> is an optional port specification that may be specified if the VNC client is not listening on port 5500, which the default port for this type of connection). The following examples show the how the boot-time option is specified for standard and non-standard ports: linux vnc vncconnect=pigdog.example.com linux vnc vncconnect=pigdog.example.com:27910 The system that is to run the listening VNC client must then launch the appropriate software to run the VNC client in its listening mode. For the VNC client supplied with &PROD; &PRODVER;, the following command is sufficient: vncviewer -listen In addition, a new kickstart directive has been added to support VNC-based installations: vnc [--password <password>] [--connect <host>[:<port>]] (Where --password <password> is an optional parameter for specifying a VNC password, and [--connect <host>[:<port>]] is an optional parameter for specifying the host (and optionally, port) of a system running a listening VNC client. NOTE: If you specify any of the VNC-related boot-time options, they will override the corresponding options present in the kickstart file. &PROD; &PRODVER; for the iSeries and pSeries architectures includes support for installation using the VNC remote display system, and support for accessing virtual consoles via telnet for installation on iSeries. VNC and telnet clients for a variety of platforms are available for download from: http://www.ibm.com/servers/eserver/iseries/linux/products.html The XFree86 open source vmware video driver is provided as a convenience to our customers and is not supported in any way by &FORMAL-RHI; However, any problem reports with the XFree86 open source vmware video driver received by &RH; will be forwarded to the appropriate VMware staff, so that they can investigate. Bug fixes that become available for this driver may be reviewed by &RH; for potential inclusion in future errata and products as time permits. Input Methods This section contains general information related to the use of input methods. An input method allows users to enter non-Western characters into common applications such as word-processing, email and instant messaging. &PROD; comes with input method support for the following languages: Chinese (Simplified and Traditional) Japanese Korean The following entries describe the use of input methods for each of these languages. Simplified Chinese To enter Simplified Chinese characters, you use the miniChinput input method. To activate the input method, press CtrlSpace. The miniChinput input method supports the following modules: · intelligent pinyin input · gbk pinyin input · shuang pin input · internal code (gb18030 code) input The miniChinput package is installed by default if Simplified Chinese language support is selected during installation. Traditional Chinese To enter Traditional Chinese characters, you use the xcin input method. To activate the input method, press CtrlSpace. Pressing ShiftCtrl or CtrlAltNum allows you to change between input modules. The xcin input method supports the following modules: · CJ · Simplex · Phone · CantonPing · Bimsphone · Bimspinyin · Array30 · Cantonping (no intonation) The xcin package is installed by default if Traditional Chinese language support is selected during installation. Japanese To enter Japanese characters, you use the Canna, FreeWnn or skk input methods. To activate the input method, press ShiftSpace. The following modules are supported: · romaji · kana (only Canna — depends on the configuration file) The Canna, FreeWnn, and skkinput packages are installed by default if Japanese language support is selected during installation. Korean To enter Korean characters, you use the ami input method. To activate the input method, press ShiftSpace. The ami package is installed by default if Korean language support is selected during installation. General Notes This section contains general notes relating to post-installation issues. &PROD; &PRODVER; for the Itanium 2 Architecture contains the fpswa.efi binary, which is an EFI (Extensible Firmware Interface) driver invoked by the operating system's kernel whenever the processor issues FPSWA (Floating-Point Software Assistance) requests for floating-point operations that are not fully implemented in hardware. The handler provides the result of the operation in these cases. Presently, Itanium processors issue FPSWA requests mainly when very small numbers (denormalized, or tiny numbers) are consumed or produced by floating-point instructions. To avoid the performance penalty caused by calls to the handler when tiny numbers are produced, the flush-to-zero mode can be turned on, but at the cost of a slightly less accurate computation. FPSWA is licensed, patented and copyrighted protected material by Intel or its supplier under the laws of the United states and other countries and international treaty provisions. FPSWA is subject to the applicable end user license agreement which can be accessed at http://www.redhat.com/licenses/. The Apache HTTP server has been updated to version 2.0. The updated package replaces version 1.3 and has been renamed to httpd. · The auth_ldap, mod_put, mod_roaming, mod_auth_any, mod_bandwidth, mod_throttle, and mod_dav modules have been removed. · WebDAV functionality is now included with the httpd package. NOTE: Some changes to existing configuration files are needed. Third-party Apache modules may also require updating. Refer to the migration guide at /usr/share/doc/httpd-*/migration.html for more details. &PROD; &PRODVER; supports booting over the network using the PXE (Pre-Boot Execution Environment) protocol. As in previous releases it is possible to configure &PROD; &PRODVER; as an installation server, which makes kernels and image files available for the purpose of starting network installations. Also available in &PROD; &PRODVER; is support for diskless environments. A diskless server (similar to an installation server) makes kernels and image files available to diskless client systems. After booting, the diskless client systems mount a root file system via NFS, eliminating the need for locally-attached storage. The Network Booting Tool (redhat-config-netboot) is a graphical configuration tool allows you to configure both environments. The LPRng print spooler has been replaced by CUPS, and the Printer Configuration Tool (redhat-config-printer) is the recommended tool for configuring it. It may be launched from the System Settings menu, using the Printing menu entry. The Security Level Configuration Tool (redhat-config-securitylevel) has been simplified. The previous "High", "Medium", and "No firewall" settings have been replaced by a more straightforward on/off-style control. In addition, the default firewall configuration is now stateful, making it more secure. The new design also makes it possible for users of NIS authentication, NFS, and DNS to deploy a firewall with no additional customization required (although customization by specifying port and protocol is still possible). NOTE: This change also applies to the &PROD; installation program. GNOME Print Manager, a simple graphical print queue management tool, is now included. It may be launched from the System Tools menu, using the Print Manager menu entry. In addition, when a print job is in the queue, an icon will appear in the panel's system notification area. &PROD; &PRODVER; includes the setarch utility. Setarch makes it possible to change the output produced by the uname command. This is useful for a number of reasons, such as running 32-bit applications (those written to expect a particular value from uname -m) in 64-bit environments. The format for the setarch command is: setarch <arch> <command> (Where <arch> represents the desired architecture string (such as i386), and <command> represents the command to be run while the architecture has been modified.) Note that <command> can be omitted, in which case /bin/sh is run. In addition, some applications (such as older versions of Java) are written to assume a 3GB virtual address space; when run on systems with larger virtual address spaces (such as 64-bit AMD64-based systems, or 32-bit systems running the hugemem kernel) such applications can malfunction. The setarch utility makes it possible to emulate a 3GB virtual address space, allowing such applications to run properly: setarch -3 java Accelerated 3D rendering with DRI has been disabled in &PROD; &PRODVER; for the IA64 architecture. On this architecture,the agpgart kernel driver does not function properly; since the DRI subsystem depends on this driver, no 3D acceleration is possible. Note, however, that this does not affect unaccelerated 3D rendering or third-party drivers that provide their own agpgart implementation. &PROD; &PRODVER; includes the Native POSIX Thread Library (NPTL), a new implementation of POSIX threads for Linux. This library provides performance improvements and increased scalability. This thread library is designed to be binary compatible with the old LinuxThreads implementation; however, applications that rely on the places where the LinuxThreads implementation deviates from the POSIX standard will need to be fixed. Notable differences include: · Signal handling has changed from per-thread signal handling to POSIX process signal handling. · getpid() returns the same value in all threads. · Thread handlers registered with pthread_atfork are not run if vfork() is used. · No manager thread. Applications that are known to have problems using NPTL include: - Sun JRE prior to version 1.4.1 - IBM JRE If an application does not work properly with NPTL, it can be run using the old LinuxThreads implementation by setting the following environment variable: LD_ASSUME_KERNEL=<kernel-version> The following versions are available: · 2.4.19 — Linuxthreads with floating stacks · 2.2.5 — Linuxthreads without floating stacks Note that software using errno, h_errno, and _res must #include the appropriate header file (errno.h, netdb.h, and resolv.h respectively) before they are used. However, LD_ASSUME_KERNEL=2.4.19 can be used as a workaround until the software can be fixed. Multi-threaded C++ programs using thread cancellation might need to be forced to use the LinuxThreads library using the LD_ASSUME_KERNEL=2.4.19 environment variable setting. Otherwise, the program will terminate abnormally if the cancellation is acted on (since the generated exception is not caught). Newly-written C++ code that uses functions from the C runtime environment might have to be adjusted to take the cancellation into account. This can be done by one of the following methods: · Not marking the C++ function with throw() (so that callers are aware that an exception might be thrown) and by compiling the code with exceptions. This is the default compilation option; users should not specify -fno-exceptions when compiling. · Disabling cancellation completely before entering the functions that call the cancel-able C runtime functions. This can be done with the following call: pthread_setcancelstate (PTHREAD_CANCEL_DISABLE, &oldstate) After the C functions are called cancellation can be enabled again with the following call: pthread_setcancelstate (oldstate, NULL) NOTE: At this point the cancellations are acted upon and therefore the function calling pthread_setcancelstate() must be compiled with exceptions enabled and must be marked as throwing exceptions. A new system message has been added to &PROD; &PRODVER;: application bug: <app-name>(<app-pid>) has SIGCHLD set to SIG_IGN but calls wait(). (see the NOTES section of 'man 2 wait'). Workaround activated. This message (which is displayed on the system console and/or in the system log files) indicates that the application is not completely standards compliant with respect to its handling of child processes. If you notice this message, you should alert the application's developers. &PROD; &PRODVER; includes the capability of producing Position Independent Executables (PIE) for C, C++, and Java. This feature is enabled with the -fpie and -fPIE GCC options to compile, which are similar in usage to the -fpic and -fPIC options, respectively, and at link time with the -pie option. The fileutils, textutils, sh-utils, and stat packages have been replaced by the newer coreutils package. The RPMs containing the Network Administration Tool (redhat-config-network) have changed names and functions. The redhat-config-network RPM contains the tool's graphical user interface, while redhat-config-network-tui contains the tool itself (along with its text-based user interface). Support for XHTML1 — the reformulation of HTML in XML — has been improved. This has been done by adding the xhtml1-dtd package, installing the DTDs in the system catalog, and adding native support in the libxml2 and xsltproc tools. The XML toolkit have been extended to support Relax-NG validation, and streaming of large files. The OProfile system-wide profiler has been added to &PROD; &PRODVER;. OProfile is a programmer's tool for analyzing system performance, using special hardware built into many modern computers. Documentation for OProfile exists in the oprofile package; after installing &PROD; &PRODVER;, issue the command rpm -qd oprofile to obtain a listing of the available documentation. Visit the OProfile website at http://oprofile.sourceforge.net for more details. NOTE: The kernel support for OProfile in &PROD; &PRODVER; is based on the backported code from the 2.5 development kernel. Therefore, if you refer to the OProfile documentation, keep in mind that features listed as being 2.5-specific actually apply to the &PROD; kernel, even though the kernel version is 2.4. Likewise, this means that features listed as being specific to the 2.4 kernel do not apply to the &PROD; kernel. At the present time, the X Window System makes use of two font subsystems, each with different characteristics: · The original (15+ year old) subsystem is referred to as the "core X font subsystem". Fonts rendered by this subsystem are not anti-aliased, are handled by the X server, and have names like: -misc-fixed-medium-r-normal--10-100-75-75-c-60-iso8859-1 The newer font subsystem is known as "fontconfig", and allows applications direct access to the font files. Fontconfig is often used along with the "Xft" library, which allows applications to render fontconfig fonts to the screen with antialiasing. Fontconfig uses more human-friendly names like: Luxi Sans-10 Over time, fontconfig/Xft will replace the core X font subsystem. At the present time, applications using the Qt 3 or GTK 2 toolkits (which would include KDE and GNOME applications) use the fontconfig and Xft font subsystem; most everything else uses the core X fonts. In the future, &RH; may support only fontconfig/Xft in place of the XFS font server as the default local font access method. NOTE: One exception to the font subsystem usage outlined above is OpenOffice.org, which uses its own font rendering technology. If you wish to add new fonts to your &PROD; &PRODVER; system, you must be aware that the steps necessary depend on which font subsystem is to use the new fonts. For the core X font subsystem, you must: 1. Create the /usr/share/fonts/local/ directory (if it does not already exist): mkdir /usr/share/fonts/local/ 2. Copy the new font file into /usr/share/fonts/local/ 3. Update the font information by issuing the following commands (note that, due to formatting restrictions, the following commands may appear on more than one line; in use, each commands should be entered on a single line): ttmkfdir -d /usr/share/fonts/local/ -o /usr/share/fonts/local/fonts.scale mkfontdir /usr/share/fonts/local/ 4. If you had to create /usr/share/fonts/local/, you must then add it to the X font server (xfs) path: chkfontpath --add /usr/share/fonts/local/ Adding new fonts to the fontconfig font subsystem is more straightforward; the new font file only needs to be copied into the /usr/share/fonts/ directory (individual users can modify their personal font configuration by copying the font file into the ~/.fonts/ directory). After the new font has been copied, use fc-cache to update the font information cache: fc-cache <directory> (Where <directory> would be either the /usr/share/fonts/ or ~/.fonts/ directories.) Individual users may also install fonts graphically, by browsing fonts:/// in Nautilus, and dragging the new font files there. NOTE: If the font filename ends with ".gz", it has been compressed with gzip, and must be decompressed (with the gunzip command) before the fontconfig font subsystem can use the font. Due to the transition to the new font system based on fontconfig/Xft, GTK+ 1.2 applications are not affected by any changes made via the Font Preferences dialog. For these applications, a font can be configured by adding the following lines to the file ~/.gtkrc.mine: style "user-font" { fontset = "<font-specification>" } widget_class "*" style "user-font" (Where <font-specification> represents a font specification in the style used by traditional X applications, such as "-adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-*".) By default, the Sendmail mail transport agent (MTA) does not accept network connections from any host other than the local computer. If you want to configure Sendmail as a server for other clients, you must edit /etc/mail/sendmail.mc and change the DAEMON_OPTIONS line to also listen on network devices (or comment out this option entirely using the dnl comment delimiter). You must then regenerate /etc/mail/sendmail.cf by running the following command (as root): make -C /etc/mail Note that you must have the sendmail-cf package installed for this to work. The default FTP server in &PROD; &PRODVER; is now vsftpd, and runs as a SysV service. Change to fdisk's interpretation of partition size multipliers The fdisk command now has a different interpretation of the size multipliers that may be used when creating new disk partitions. The size suffixes K, M, and G now refer to multiples of thousands, millions, and billions of bytes, respectively. This is more consistent with the disk size specifications provided by disk drive manufacturers. Therefore, if a user wants to create a 512MB partition, the size value specified with an "M" suffix would be 512*1024*1024 (536,870,912), rounded up to a multiple of a million (537,000,000), and then divided by a million (537), resulting in a size specification of +537M. While compatibility for executables and dynamic shared objects (DSOs, also known as shared libraries) created on earlier &RHL; and &PROD; is supported, the same does not apply to object (.o) files. Object files created on earlier versions can be used on &PROD; &PRODVER; to create new executables or DSOs only if they were built without including any system header files. Otherwise, the only way to use these files is to link the object files to the compatibility version of glibc (part of the compat-glibc package). Any newly-generated object file must use the headers from the compatibility package. For example, to compile object files, add the following to the beginning of the compiler command line: -I/usr/lib/i386-redhat-linux7/include To link the resulting executable or DSO add the following to the command line: -L/usr/lib/i386-redhat-linux7/lib Any mixture of old object files and those compiled against the current system headers can have negative results. Linking old object files with the regular system libraries may result in completely unusable executables or executables with subtle bugs (such as memory corruption). Kernel Notes This section contains notes relating to the &PROD; &PRODVER; kernel. The &PROD; &PRODVER; kernel makes use of a new kernel packaging technique. Due to the almost limitless variety of available hardware, it is not possible for &RH; to fully support all hardware components. Therefore, while kernel modules for fully-supported hardware remain in the standard kernel packages, a series of new unsupported kernel packages are included with &PROD; &PRODVER;. For each kernel package shipped there is a corresponding unsupported kernel package. For example, the unsupported kernel package for kernel-smp-2.4.21-3.EL.i686.rpm is kernel-smp-unsupported-2.4.21-3.EL.i686.rpm. NOTE: The unsupported kernel packages are not installed by the &PROD; installation program; therefore, in order to use unsupported kernel modules, you must manually install the unsupported kernel package corresponding to the kernel your system uses. After installing the appropriate unsupported kernel package, you must use the following command to update the module dependency tree and your initrd: /sbin/new-kernel-pkg --mkinitrd --depmod --install <kernel-version> (Where <kernel-version> represents the version of the installed kernel.) Drivers contained within the unsupported kernel packages are provided on a best-effort basis. This means that updates and upstream fixes may or may not be incorporated over time, and are not covered by the same support expectations as the fully supported drivers. Custom support arrangements covering drivers in the unsupported package may be worked out with Red Hat in some situations. The &PROD; &PRODVER; kernel includes more accurate process timing functionality. This new process timing mode uses timestamps to provide more accurate timing of idle and process times. When enabled, this information is available via the usual monitoring tools (such as top, vmstat, and procinfo), and the getrusage system call. To enable timestamp-based process timing, you must boot your system using the following boot-time option: process_timing=<value> Where <value> can be one or more of the following, with multiple values separated by commas: · irq — Use timestamps to account for IRQ interrupts · softirq — Use timestamps to account for softirq time in the kernel · process — Allow processes to enable timestamp-based process timing on themselves (It is then disabled for all processes by default) · all_process — Force timestamp-based process timing on all processes (including the idle tasks) · everything — Same as specifying irq,softirq,all_process If the system is booted with the process option, no processes initially have timestamp-based process timing enabled by default. However, processes can use the prctl() system call to both determine and modify their process timing mode. The system call to determine the process timing mode is: mode = prctl(PR_GET_TIMING, 0, 0, 0, 0); The system call to set the process timing mode is: status = prctl(PR_SET_TIMING, <mode>, 0, 0, 0) (Where <mode> is PR_TIMING_STATISTICAL for enabling the traditional process timing mode, or PR_TIMING_TIMESTAMP for enabling timestamp-based process timing mode .) Note that enabling one process timing mode automatically disables the other. NOTE: The prctl() system call can only be used on systems booted with the process value. Otherwise, the system call will return -EINVAL. This includes attempts to disable timestamp-based process timing on systems booted with the all_process option. A child process's timing mode is inherited from its parent; however, the child can use the prctl() system call to modify its own process timing mode (subject to the conditions outlined in the previous note). The BusLogic driver (for certain Mylex SCSI host bus adapters) is provided in the standard kernel packages, but it is only supported when the kernel is a guest operating system within VMWare virtual machine software. This is because VMWare presents an emulated SCSI adapter to the BusLogic driver, and this environment has been thoroughly tested and supported by VMWare, Inc. The BusLogic driver is not supported on physical SCSI host adapters because this driver has not been maintained in the official Linux kernel for several years, and has not received extensive testing in the &RHEL; kernel. The qla1280 driver (for the Qlogic ISP1x80/1x160 SCSI adapters) has not been maintained in the official Linux kernel for many years. As a result, although this driver works correctly with the Intel x86 architecture, it does not work correctly with other architectures. Therefore, &RH; only supports the qla1280 driver on Intel x86 platforms. The netdump facility is currently disabled. The netdump package is included so that, if the netdump facility is enabled in a future kernel update, netdump functionality will be available after the netdump-capable kernel is installed. Systems based on the Intel I865/I875 chipsets and utilizing these chipsets' ICH5 integrated AC97 audio functionality may experience a failure to produce any sound when running &PROD; &PRODVER;. The ICH5 integrated AC97 audio subsystem can be identified by reviewing the output from the following command: /sbin/lspci -n The PCI vendor:device code for the ICH5 AC97 audio is 8086:24d5. Systems based on the Intel I865/I875 chipsets and utilizing these chipsets' ICH5 Serial ATA (SATA) functionality should configure the BIOS settings for their SATA devices to "enhanced" or "native" mode. "Legacy" or "combined" mode SATA is supported, but discouraged. NOTE: Not all BIOS implementations offer the ability to change these settings. New kernel support has been added to provide IPv6 capabilities. This support is consistent with the upstream 2.6-based implementation as of 2.6.0-test3. Note that &RH; will not be implementing additional IPv6 features (such as any of the draft standards for Mobile IP) for this release of &PROD;; our goal is to focus exclusively on bugs in existing features. EA (Extended Attributes) and ACL (Access Control Lists) functionality is now available for ext3 file systems. In addition, ACL functionality is available for NFS. &PROD; &PRODVER; contains a kernel providing EA and ACL support for the ext3 file system. Protocol extensions were also added to NFS to support ACL-related operations for NFS-exported file systems. To enable ACLs on a locally-mounted file system, the file system must be mounted with the -o acl mount option. By default, the NFS server makes use of ACLs if the underlying file system supports them. To disable this feature, you must specify the no_acl export option. EAs are used intrinsically for ACL support. To use EAs separately, the file system must be mounted with the -o user_xattr mount option. The support for this comes in several packages: · kernel — Provides support for storing EAs and ACLs on disk for ext3 file systems, as well the system calls to manipulate EAs and ACLs. Finally, the kernel package provides the mechanisms to enforce ACLs on file access. · e2fsprogs — Includes knowledge of the new on-disk extended attribute formats so that fsck can check file systems using the new feature. · attr, libattr — Provides access to extended attributes attached to files. · acl, libacl — Provides tools to set, modify, and query the ACLs set on files. · libattr-devel, libacl-devel — Libraries and include files to build programs using the acl and attr libraries. · star — An archiving tool which can create and unpack both tar and pax format archives, and which can backup and restore EAs and ACLs. NOTE: The options available for star are not completely equivalent with those available for tar; therefore, make sure you review the star man page. · samba — Samba can export ACL functionality in this release. Refer to the samba documentation for information on how to enable this in your configuration. In addition, the coreutils package has been updated so that the cp and mv commands copy the ACLs and EAs associated with a file. For more information on setting and reading ACLs, refer to the setfacl and getfacl man pages. General information about ACLs can be found in the acl man page. NOTE: The normal tar and dump commands will not backup ACLs and EAs. Compatibility with older systems: Any ext3 file system that has not had any ACLs or EAs set on it will work unchanged on older kernels, and can be checked using older e2fsprogs utilities. Once an EA or an ACL has been set on any file on a given file system, that file system will acquire the ext_attr attribute. This attribute can be observed by using the following command: tune2fs -l <filesystemdevice> A file system that has acquired the ext_attr attribute can be mounted with older kernels, but obviously those kernels are incapable of enforcing any ACLs that have been set. NOTE: Older versions of the file system checking program e2fsck refuse to check any file system with the ext_attr attribute. This corresponds to versions of the e2fsprogs package prior to 1.22. The &PROD; &PRODVER; kernel now includes support for NFS over TCP. To use NFS over TCP, you must include the "-o tcp" option to mount when mounting the NFS-exported file system on the client system. NOTE: The default transport protocol for NFS remains UDP. Use the mount command with the "-o tcp" option to mount an NFS-exported file system using TCP; otherwise, UDP will be used by default. In this kernel, the following command has been added to scan for new devices on all attached SCSI host adapters: echo "scsi scan-new-devices" > /proc/scsi/scsi This is currently a non-standard addition. In future kernels a different parameter may be used to provide the same capability, or the semantics of the same parameter (scan-new-devices) may change, as &RH; tracks the official Linux kernel in this area. Logical Partitions on iSeries platforms that have been configured to use more than one processor (either directly or from a shared pool) may wish to share interrupt processing across all processors. Doing so may improve performance for some workloads. By default, &PROD; will only service interrupts on one processor in the LPAR. To change this behavior, the following boot-time option must be entered: spread_lpevents=<N> Where <N> represents the number of processors in the LPAR that should process interrupts. This number should be less than or equal to either: · The number of virtual processors (if a shared processor pool is being used) · The number of direct processors assigned to the LPAR Change in permission semantics for user-mode memory locking &PROD; &PRODVER; now allows non-root processes to use user-mode memory locking system calls within the bounds of their RLIMIT_MEMLOCK resource limit. The default limit is one physical page per process. Limits can be reassigned by the system administrator on a per user-id, per group-id, or system-wide basis via the /etc/security/limits.conf file. Root processes are no longer constrained by this resource limit. The system calls affected by this change in semantics are mlock(2), munlock(2), mlockall(2), munlockall(2), and shmctl(2). ( x86 ia64 s390 s390x amd64 ppc )
--- NEW FILE announcement-release.txt --- # This file collects notes throughout the release that are # used for the announcement and/or the splash.xml. - newer/better/faster/more - OpenOffice 2.0 pre - GNOME 2.10 featuring Clearlooks - KDE 3.4 - Eclipse & the java stack, in all its huge glory - Extras by default at release time - PPC now included - OO.org 2.0 - Evince first release - Newer, better GFS fun - Virtualization available with built-in Xen - GCC 4.0 - 80 new daemons covered by SELinux (up from a dozen) Just part of Gnome 2.10, but since it's such a visible change, maybe mention the new default theme. --- NEW FILE daemons.xml ---
System Services
<filename>cron</filename> and <filename>slocate</filename> The updatedb utility is no longer automatically run by cron to create and update the database of files used by slocate. Updating this database is an intensive process that users of workstations and laptops may find disruptive. To enable daily updates of the slocate database, edit the file /etc/updatedb.conf as follows: DAILY_UPDATE=yes --- NEW FILE database-servers.xml --- --- NEW FILE desktop.xml --- --- NEW FILE development-tools.xml ---
Development Tools
GCC Compiler Collection &DISTRO; &DISTROVER; has been built using GCC 4.0, which is included with the distribution. Caveats GDB 6.1 or newer is needed to debug binaries unless compiled using the -fno-var-tracking compilation option. The -fwritable-strings option is no longer accepted. English-language diagnostic messages now use Unicode quotes; if you cannot read this, set your LC_CTYPE environment variable to "C" or change your terminal emulator. The specs file is no longer installed on most systems. Ordinary users will not notice, but developers who need to alter the file can use the -dumpspecs option to generate the file for editing. Code Generation The SSA code optimizer is now included and brings with it better constant propagation, partial redundancy elimination, load and store code motion, strength reduction, dead storage elimination, better detection of unreachable code, and tail recursion by accumulation. Autovectorization is supported. This technique achieves higher performance for repetitive loop code, in some circumstances. Language Extentions A sentinel attribute has been added so that the compiler will now issue a warning if a function such as execl(char *path, const char *arg, ...), which requires a NULL list terminator is missing the NULL. The cast-as-lvalue, conditional-expression-as-lvalue, and compund-expression-as-lvalue extentions have been removed. The #pragma pack() semantics have been brought closer to those used by other compilers. Taking the address of a variable declared with the register modifier now generates an error instead of a warning. Arrays of incomplete element types now generate an error. This implies no forward reference to structure definitions. The basic compiler, without any optimization (-O0), has been measured as much as 25% faster in real-world code. Libraries may now contain function-scope static variables in multi-threaded programs. The -fno-threadsafe-statics can be used by embedded developers to turn off this feature, but ordinary users should never do this. Java To avoid naming conflicts: rmic is now grmic; rmiregistry is now grmiregistry; and jar is now fastjar. The GCJ compiler can now be used as a just-in-time (JIT) tool by using the gnu.jit facilities. More support of the AWT and SWING packages have been added. FORTRAN The GNU FORTRAN 77 front end has been replaced by a new FORTRAN 90/95 recognizer. Eclipse Development Environment Eclipse 3.1M6 has been compiled as a native application. The C Development Tool (CDT) has been included.
--- NEW FILE eula.py --- from gtk import * import string import gtk import gobject import sys import functions import rhpl.iconv import os ## ## I18N ## import gettext gettext.bindtextdomain ("firstboot", "/usr/share/locale") gettext.textdomain ("firstboot") _=gettext.gettext class childWindow: #You must specify a runPriority for the order in which you wish your module to run runPriority = 15 moduleName = (_("License Agreement")) def launch(self, doDebug = None): self.doDebug = doDebug if self.doDebug: print "initializing eula module" self.vbox = gtk.VBox() self.vbox.set_size_request(400, 200) msg = (_("License Agreement")) title_pix = functions.imageFromFile("workstation.png") internalVBox = gtk.VBox() internalVBox.set_border_width(10) internalVBox.set_spacing(5) textBuffer = gtk.TextBuffer() textView = gtk.TextView() textView.set_editable(gtk.FALSE) textSW = gtk.ScrolledWindow() textSW.set_shadow_type(gtk.SHADOW_IN) textSW.set_policy(gtk.POLICY_AUTOMATIC, gtk.POLICY_AUTOMATIC) textSW.add(textView) lang = os.environ["LANG"] if len(string.split(lang, ".")) > 1: lang = string.split(lang, ".")[0] path = "/usr/share/eula/eula.%s" % lang if not os.access(path, os.R_OK): #Try to open the translated eula lines = open("/usr/share/eula/eula.en_US").readlines() else: #If we don't have a translation for this locale, just open the English one lines = open(path).readlines() iter = textBuffer.get_iter_at_offset(0) for line in lines: textBuffer.insert(iter, line) textView.set_buffer(textBuffer) self.okButton = gtk.RadioButton(None, (_("_Yes, I agree to the License Agreement"))) self.noButton = gtk.RadioButton(self.okButton, (_("N_o, I do not agree"))) self.noButton.set_active(gtk.TRUE) internalVBox.pack_start(textSW, gtk.TRUE) internalVBox.pack_start(self.okButton, gtk.FALSE) internalVBox.pack_start(self.noButton, gtk.FALSE) self.vbox.pack_start(internalVBox, gtk.TRUE, 5) return self.vbox, title_pix, msg def apply(self, notebook): if self.okButton.get_active() == gtk.TRUE: return 0 else: dlg = gtk.MessageDialog(None, 0, gtk.MESSAGE_QUESTION, gtk.BUTTONS_NONE, (_("Do you want to reread or reconsider the Licence Agreement? " "If not, please shut down the computer and remove this " "product from your system. "))) dlg.set_position(gtk.WIN_POS_CENTER) dlg.set_modal(gtk.TRUE) continueButton = dlg.add_button(_("_Reread license"), 0) shutdownButton = dlg.add_button(_("_Shut down"), 1) continueButton.grab_focus() rc = dlg.run() dlg.destroy() if rc == 0: return None elif rc == 1: if self.doDebug: print "shut down system" os.system("/sbin/halt") return None --- NEW FILE eula.txt --- LICENSE AGREEMENT FEDORA(TM) CORE 3 This agreement governs the download, installation or use of the Software (as defined below) and any updates to the Software, regardless of the delivery mechanism. The Software is a collective work under U.S. Copyright Law. Subject to the following terms, Fedora Project grants to the user ("User") a license to this collective work pursuant to the GNU General Public License. By downloading, installing or using the Software, User agrees to the terms of this agreement. 1. THE SOFTWARE. Fedora Core (the "Software") is a modular Linux operating system consisting of hundreds of software components. The end user license agreement for each component is located in the component's source code. With the exception of certain image files containing the Fedora trademark identified in Section 2 below, the license terms for the components permit User to copy, modify, and redistribute the component, in both source code and binary code forms. This agreement does not limit User's rights under, or grant User rights that supersede, the license terms of any particular component. 2. INTELLECTUAL PROPERTY RIGHTS. The Software and each of its components, including the source code, documentation, appearance, structure and organization are copyrighted by Fedora Project and others and are protected under copyright and other laws. Title to the Software and any component, or to any copy, modification, or merged portion shall remain with the aforementioned, subject to the applicable license. The "Fedora" trademark is a trademark of Red Hat, Inc. ("Red Hat") in the U.S. and other countries and is used by permission. This agreement permits User to distribute unmodified copies of Software using the Fedora trademark on the condition that User follows Red Hat's trademark guidelines located at http://fedora.redhat.com/legal. User must abide by these trademark guidelines when distributing the Software, regardless of whether the Software has been modified. If User modifies the Software, then User must replace all images containing the "Fedora" trademark. Those images are found in the anaconda-images and the fedora-logos packages. Merely deleting these files may corrupt the Software. 3. LIMITED WARRANTY. Except as specifically stated in this agreement or a license for a particular component, TO THE MAXIMUM EXTENT PERMITTED UNDER APPLICABLE LAW, THE SOFTWARE AND THE COMPONENTS ARE PROVIDED AND LICENSED "AS IS" WITHOUT WARRANTY OF ANY KIND, EXPRESSED OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT OR FITNESS FOR A PARTICULAR PURPOSE. Neither the Fedora Project nor Red Hat warrants that the functions contained in the Software will meet User's requirements or that the operation of the Software will be entirely error free or appear precisely as described in the accompanying documentation. USE OF THE SOFTWARE IS AT USER'S OWN RISK. 4. LIMITATION OF REMEDIES AND LIABILITY. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, FEDORA PROJECT AND RED HAT WILL NOT BE LIABLE TO USER FOR ANY DAMAGES, INCLUDING INCIDENTAL OR CONSEQUENTIAL DAMAGES, LOST PROFITS OR LOST SAVINGS ARISING OUT OF THE USE OR INABILITY TO USE THE SOFTWARE, EVEN IF FEDORA PROJECT OR RED HAT HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 5. EXPORT CONTROL. As required by U.S. law, User represents and warrants that it: (a) understands that the Software is subject to export controls under the U.S. Commerce Department's Export Administration Regulations ("EAR"); (b) is not located in a prohibited destination country under the EAR or U.S. sanctions regulations (currently Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria); (c) will not export, re-export, or transfer the Software to any prohibited destination, entity, or individual without the necessary export license(s) or authorizations(s) from the U.S. Government; (d) will not use or transfer the Software for use in any sensitive nuclear, chemical or biological weapons, or missile technology end-uses unless authorized by the U.S. Government by regulation or specific license; (e) understands and agrees that if it is in the United States and exports or transfers the Software to eligible end users, it will, as required by EAR Section 741.17(e), submit semi-annual reports to the Commerce Department's Bureau of Industry & Security (BIS), which include the name and address (including country) of each transferee; and (f) understands that countries other than the United States may restrict the import, use, or export of encryption products and that it shall be solely responsible for compliance with any such import, use, or export restrictions. 6. GENERAL. If any provision of this agreement is held to be unenforceable, that shall not affect the enforceability of the remaining provisions. This agreement shall be governed by the laws of the State of North Carolina and of the United States, without regard to any conflict of laws provisions, except that the United Nations Convention on the International Sale of Goods shall not apply. Copyright (C) 2003, 2004 Fedora Project. All rights reserved. "Red Hat" and "Fedora" are trademarks of Red Hat, Inc. "Linux" is a registered trademark of Linus Torvalds. All other trademarks are the property of their respective owners. --- NEW FILE fedora-devel.repo --- [development] name=Fedora Core $releasever - Development Tree #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/ mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-rawhide enabled=0 --- NEW FILE fedora-release.spec --- %define builtin_release_version @VERSION@ %define builtin_release_name @RELNAME@ %define real_release_version %{?release_version}%{!?release_version:%{builtin_release_version}} %define real_release_name %{?release_name}%{!?release_name:%{builtin_release_name}} Summary: Fedora Core release file Name: fedora-release Version: %{real_release_version} Release: 9 Copyright: GFDL Group: System Environment/Base Source: fedora-release-%{builtin_release_version}- at RELARCH@.tar.gz Obsoletes: rawhide-release Obsoletes: redhat-release Obsoletes: indexhtml Provides: redhat-release Provides: indexhtml BuildRoot: %{_tmppath}/fedora-release-root ExclusiveArch: @RELARCH@ %description Fedora Core release file %prep %setup -q -n fedora-release- at VERSION@- at RELARCH@ %build python -c "import py_compile; py_compile.compile('eula.py')" %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT/etc echo "Fedora Core release %{real_release_version} (%{real_release_name})" > $RPM_BUILD_ROOT/etc/fedora-release cp $RPM_BUILD_ROOT/etc/fedora-release $RPM_BUILD_ROOT/etc/issue echo "Kernel \r on an \m" >> $RPM_BUILD_ROOT/etc/issue cp $RPM_BUILD_ROOT/etc/issue $RPM_BUILD_ROOT/etc/issue.net echo >> $RPM_BUILD_ROOT/etc/issue ln -s fedora-release $RPM_BUILD_ROOT/etc/redhat-release mkdir -p $RPM_BUILD_ROOT/usr/share/eula $RPM_BUILD_ROOT/usr/share/firstboot/modules cp -f eula.txt $RPM_BUILD_ROOT/usr/share/eula/eula.en_US cp -f eula.py $RPM_BUILD_ROOT/usr/share/firstboot/modules/eula.py mkdir -p -m 755 $RPM_BUILD_ROOT/%{_defaultdocdir}/HTML cp -ap img css \ $RPM_BUILD_ROOT/%{_defaultdocdir}/HTML for file in indexhtml-*.html ; do newname=`echo $file | sed 's|indexhtml-\(.*\)-\(.*\).html|index-\2.html|g'` install -m 644 $file $RPM_BUILD_ROOT/%{_defaultdocdir}/HTML/$newname || : done mv -f $RPM_BUILD_ROOT/%{_defaultdocdir}/HTML/index-en.html \ $RPM_BUILD_ROOT/%{_defaultdocdir}/HTML/index.html || : mkdir -p -m 755 $RPM_BUILD_ROOT/etc/sysconfig/rhn mkdir -p -m 755 $RPM_BUILD_ROOT/etc/yum.repos.d install -m 644 sources $RPM_BUILD_ROOT/etc/sysconfig/rhn/sources for file in fedora*repo ; do install -m 644 $file $RPM_BUILD_ROOT/etc/yum.repos.d done %clean rm -rf $RPM_BUILD_ROOT # If this is the first time a package containing /etc/issue # is installed, we want the new files there. Otherwise, we # want %config(noreplace) to take precedence. %triggerpostun -- redhat-release < 7.1.93-1 for I in issue issue.net; do if [ -f /etc/$I.rpmnew ] ; then mv -f /etc/$I /etc/$I.rpmsave mv -f /etc/$I.rpmnew /etc/$I fi done %files %defattr(-,root,root) %attr(0644,root,root) /etc/fedora-release /etc/redhat-release %dir /etc/sysconfig/rhn %dir /etc/yum.repos.d %config(noreplace) /etc/sysconfig/rhn/sources %config(noreplace) /etc/yum.repos.d/* %doc R* %doc eula.txt GPL autorun-template %config %attr(0644,root,root) /etc/issue %config %attr(0644,root,root) /etc/issue.net /usr/share/firstboot/modules/eula.py /usr/share/eula/eula.en_US %{_defaultdocdir}/HTML --- NEW FILE fedora-updates-testing.repo --- [updates-testing] name=Fedora Core $releasever - $basearch - Test Updates #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/$releasever/$basearch/ mirrorlist=http://fedora.redhat.com/download/mirrors/updates-testing-fc$releasever enabled=0 gpgcheck=1 --- NEW FILE fedora-updates.repo --- [updates-released] name=Fedora Core $releasever - $basearch - Released Updates #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/updates/$releasever/$basearch/ mirrorlist=http://fedora.redhat.com/download/mirrors/updates-released-fc$releasever enabled=1 gpgcheck=1 --- NEW FILE fedora.css --- /* CSS for Red Hat Linux Project docs from the Documentation Project Written by Tammy Fox and Garrett LeSage Copyright 2003 Tammy Fox, Garrett LeSage, and Red Hat, Inc. License: GPL */ li p { display: inline; } div.table table { width: 95%; background-color: #DCDCDC; color: #000000; border-spacing: 0; } div.table table th { border: 1px solid #A9A9A9; background-color: #A9A9A9; color: #000000; } div.table table td { border: 1px solid #A9A9A9; background-color: #DCDCDC; color: #000000; padding: 0.5em; margin-bottom: 0.5em; margin-top: 2px; } div.note table, div.tip table, div.important table, div.caution table, div.warning table { width: 95%; border: 2px solid #B0C4DE; background-color: #F0F8FF; color: #000000; /* padding inside table area */ padding: 0.5em; margin-bottom: 0.5em; margin-top: 0.5em; } .qandaset table { border-collapse: collapse; } .qandaset { } .qandaset tr.question { } .qandaset tr.question td { font-weight: bold; padding: 1em 1em 0; } .qandaset tr.answer td { padding: 0.25em 1em 1.5em; } .qandaset tr.question td, .qandaset tr.answer td { } hr { border: 0; border-bottom: 1px solid #ccc; } h1, h2, h3, h4 { font-family: luxi sans,sans-serif; color: #990000; font-weight: bold; } h1 { font-size: 1.75em; } h2 { font-size: 1.25em; } h3 { font-size: 1.1em; } code.screen, pre.screen { font-family: monospace; font-size: 1em; display: block; padding: 10px; border: 1px solid #bbb; background-color: #eee; color: #000; overflow: auto; border-radius: 2.5px; -moz-border-radius: 2.5px; margin: 0.5em 2em; } div.example { padding: 10px; border: 1px solid #bbb; margin: 0.5em 2em; } .procedure ol li { margin-bottom: 1.5em; } /* prevent inheritance */ .procedure ol li li { margin-bottom: 0em; } --- NEW FILE fedora.repo --- [base] name=Fedora Core $releasever - $basearch - Base #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/$releasever/$basearch/os/ mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-$releasever enabled=1 gpgcheck=1 --- NEW FILE feedback.xml ---
Release Notes Feedback Procedure (This section will disappear when the final &DISTRO; release is created.) If you feel that these release notes could be improved in some way, you can provide feedback directly to the author. If you see a URL in the release notes that looks like this: %%% https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=<bug-number> %%% You can click on the URL and submit feedback on that particular section of the release notes. Your feedback will be added as a comment to an existing bug report. If the section of the release notes that you have feedback for does not have one of these URLs (or you are submitting a request for entirely new content), you can click on the following link (this only works for the HTML version, of course — the URL is much too long to include in the text): Click here to submit new release notes feedback If you would like to review the changes that have been already submitted for this document, use the following link: http://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=114398 As bugs are posted for the various parts of the release notes, subsequent test versions of these release notes will contain links similar to the one described earlier. Thank you (in advance) for your feedback!
--- NEW FILE file-servers.xml ---
File Servers This section refers to file transfer and sharing servers. Please refer to the &WEB-SERVERS; and &SAMBA; sections for information on HTTP (Web) file transfer and Samba (Windows) file sharing.
Netatalk (Macintosh Compatibility) This section contains information related to Netatalk, a suite of software that enables Linux to interact with Macintosh systems using the AppleTalk network protocols.
<filename>netatalk</filename> &DISTRO; &DISTROVER; includes version 2 of Netatalk. Upgrading from Netatalk version 1 to version 2 may result in data loss. Version 2 of Netatalk uses a different method to store file resource forks from the previous version, and may require a different file name encoding scheme. Please read the documentation and plan your migration before upgrading. Upgrade information is available directly from the Netatalk site: http://netatalk.sourceforge.net/2.0/htmldocs/upgrade.html The documentation is also included in the netatalk package. Refer to either /usr/share/doc/netatalk-2.0.2/doc/htmldocs/upgrade.html, or /usr/share/doc/netatalk-2.0.2/doc/Netatalk-Manual.pdf (numbered page 25, document page 33).
--- NEW FILE file-systems.xml --- --- NEW FILE hardware-reqs.xml ---
Hardware Requirements The following information represents the minimum hardware requirements necessary to successfully install &DISTRO; &DISTROVER;. Note The compatibility/availability of other hardware components (such as video and network cards) may be required for specific installation modes and/or post-installation usage.
CPU Requirements This section lists the CPU specifications required by &DISTRO; &DISTROVER;. <!-- <remark os="test">(x86)</remark>--> Note The following CPU specifications are stated in terms of Intel processors. Other processors (notably, offerings from AMD, Cyrix, and VIA) that are compatible with and equivalent to the following Intel processors may also be used with &DISTRO;. Minimum: Pentium-class — &FC; &LOCALVER; is optimized for Pentium 4 CPUs, but also supports earlier CPUs (such as Pentium, Pentium Pro, Pentium II, Pentium III, and including AMD and VIA variants). This approach has been taken because Pentium-class optimizations actually result in reduced performance for non-Pentium-class processors, and Pentium 4 scheduling is sufficiently different (while making up the bulk of today's processors) to warrant this change. Recommended for text-mode: 200 MHz Pentium-class or better Recommended for graphical: 400 MHz Pentium II or better AMD64 processors (both Athlon64 and Opteron) Intel processors with Intel Extended Memory 64 Technology (Intel EM64T)
Hard Disk Space Requirements This section lists the disk space required to install &DISTRO; &DISTROVER;. Note The disk space requirements listed below represent the disk space taken up by &DISTRO; &DISTROVER; after the installation is complete. However, additional disk space is required during the installation to support the installation environment. This additional disk space corresponds to the size of /Fedora/base/stage2.img (on CD-ROM 1) plus the size of the files in /var/lib/rpm on the installed system. In practical terms, this means that as little as an additional 90MB can be required for a minimal installation, while as much as an additional 175MB can be required for an "everything" installation. Also, keep in mind that additional space will be required for any user data, and at least 5% free space should be maintained for proper system operation. This list is for 32-bit x86 systems: Custom Installation (Minimal): 620MB Server: 1.1GB Personal Desktop: 2.3GB Workstation: 3.0GB Custom Installation (Everything): 6.9GB This list is for 64-bit x86_64 systems: Custom Installation (Minimal): 900MB Server: 1.5GB Personal Desktop: 2.7GB Workstation: 3.4GB Custom Installation: (Everything) 7.5GB
Memory Requirements This section lists the memory required to install &DISTRO; &DISTROVER;. This list is for 32-bit x86 systems: Minimum for text-mode: 64MB Minimum for graphical: 192MB Recommended for graphical: 256MB This list is for 64-bit x86_64 systems: Minimum for text-mode: 128MB Minimum for graphical: 256MB Recommended for graphical: 512MB
PPC Hardware Requirements This section lists the minimum PowerPC (PPC) hardware needed to install &FC; &LOCALVER;. Minimum: PowerPC G3 / POWER4 &FC; &LOCALVER; supports only the New World generation of Apple Power Macintosh, shipped circa 1999 onwards. It also supports the 64-bit G5 processor and, POWER processors in IBM eServer pSeries. Currently 32-bit IBM RS/6000 machines are not supported. Recommended for text-mode: 233 MHz G3 or better Recommended for graphical: 400 MHz G3 or better
--- NEW FILE install-notes.xml ---
Installation-Related Notes This section outlines those issues that are related to Anaconda (the &DISTRO; installation program) and installing &DISTRO; &DISTROVER; in general. Note If you intend to download the &DISTRO; &DISTROVER; DVD ISO image, keep in mind that not all file downloading tools can accommodate files larger than 2GB in size. For example, wget will exit with a File size limit exceeded error. The curl and ncftpget file downloading tools do not have this limitation, and can successfully download files larger than 2GB. Bittorrent is another method for downloading large files. For information about obtaining and using the torrent file refer to this website: http://torrent.fedoraproject.org/
PPC Installation Notes The DVD or first CD of the installation set of &FC; is set to be bootable on the Apple Macintosh and should boot the appropriate 32-bit or 64-bit installer. In addition, bootable CD images can be found in the images/ directory of the DVD or first CD. Choose the appropriate boot.iso according to the hardware: images/mac/boot.iso - 32-bit Apple Macintosh (G3/G4) images/mac64/boot.iso - 64-bit Apple Macintosh (G5) images/pseries/boot.iso - 64-bit IBM eServer pSeries (POWER4/POWER5) Power management support, including sleep and backlight level management, is present in the apmud package, which is in &FEX;. &FEX; for &FC; is configured by default for yum. Following installation, apmud can be installed by running yum install apmud.
Anaconda Notes The &DISTRO; installation program has the ability to test the integrity of the installation media. It works with the CD, DVD, hard drive ISO, and NFS ISO installation methods. &RH; recommends that you test all installation media before starting the installation process, and before reporting any installation-related bugs (many of the bugs reported are actually due to improperly-burned CDs). To use this test, type linux mediacheck at the boot: prompt. The mediacheck function is highly sensitive, and may report some usable discs as faulty. This result is often caused by disc writing software that does not include padding when creating discs from ISO files. For best results with the mediacheck, boot with the option: linux ide=nodma Use the sha1sum utility to verify discs before carrying out an installation. This test accurately identifies discs that are not valid or identical to the ISO image files. Memory testing may be performed prior to installing &DISTRO; by entering memtest86 at the boot: prompt. This causes the Memtest86 standalone memory testing software to run. Memtest86 memory testing continues until the Esc key is pressed. NOTE: You must boot from CD-ROM 1 (or a rescue CD-ROM) in order to use this feature. &DISTRO; &DISTROVER; supports graphical FTP and HTTP installations. However, due to the necessity of containing the installer image in RAM, only systems with more than 128MB of RAM (or systems booted from CD-ROM 1, which contains the installer image) can use the graphical installer. Systems with 128MB or less will continue to use the text-based installer.
Installation-Related Issues Certain hardware configurations (particularly those with LCD displays) may experience problems while starting the &DISTRO; installation program. In these instances, restart the installation, and add the "nofb" option to the boot command line. Note Chinese, Japanese, and Korean graphical installations started using the "nofb" option will start in English, and then switch to the appropriate language once the graphical phase of the installation process begins. Some Sony VAIO notebook systems may experience problems installing &DISTRO; from CD-ROM. If this happens, restart the installation process and add the following option to the boot command line: pci=off ide1=0x180,0x386 This option allows the installation to proceed normally; any devices not detected due to the use of this option will be configured the first time &DISTRO; is booted. Serial mice are known to be inoperative during installation. However, there are indications that serial mice work properly in X after the installation has completed. Refer to bug 119474 for more information: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119474 There have been issues observed when upgrading &RHL; 7.<x>, 8.0, 9, and &FC; 1, 2, and 3 systems where third party packages are installed that conflict with packages provided by &FP;. One example is Ximian GNOME. The issue with Ximian GNOME is caused by version overlap between the official &RHL; RPMs (or the ones from the &PROJ;) and the Ximian RPMs. This configuration is not supported. You have several choices in resolving this particular issue: You may remove Ximian GNOME from your system prior to upgrading to &DISTRO;. You may upgrade your system, and then immediately reinstall Ximian GNOME. You may upgrade your system, and then immediately remove all remaining Ximian RPMs, replacing them with the corresponding &DISTRO; RPMs. You must resolve the version overlap using one of the above choices. Failure to do so will result in an unstable GNOME configuration.
--- NEW FILE intro.xml ---
Introduction and Technical Release Notes The &PROJ; is an openly-developed project designed by &RH;, open for general participation, led by a meritocracy, and following a set of project objectives. The results from this project include &DISTRO;, which is a complete, general-purpose operating system built exclusively from open source software. Note &FC; is a community supported project. &FC; is not a commercially supported product of &FORMAL-RHI;. For more information, refer to . Additional important information about this release may be made available at http://fedora.redhat.com/docs/release-notes/. Users are advised to check this link regularly for updates. For reporting errors or other requests about these release notes, file a bug report using this pre-filled bugzilla template. This &TINY-BUG-URL; will take you to the same pre-filled bugzilla template.
--- NEW FILE java-package.xml ---
Java Package Recommendations &FC; &LOCALVER; users are advised not to use the Java RPM provided by Sun. It contains Provides that conflict with names used in packages provided as part of &FC; &LOCALVER;. Because of this, Sun Java might disappear from an installed system during package upgrade operations. &FC; &LOCALVER; users should use either the RPM from jpackage.org or manually install the Sun Java tarball into /opt. Sun Java 1.5+ is recommended for stability purposes.
--- NEW FILE kernel.xml ---
Linux Kernel
Version The &DISTRO; is based on a 2.6.11 kernel. &FC; may include additional patches for improvements, bug fixes, or additional features. For this reason, the &FC; kernel may not be line-for-line equivalent to the so-called vanilla kernel from the kernel.org web site. You may obtain a list of any such patches by using the command on the &FC; package: rpm -qpl kernel-<version>.src.rpm
Kernel Flavors &FC; includes the following kernel builds: Native kernel, in both uniprocessor and SMP varieties. Configured sources are available in the kernel-devel-<version>.<arch>.rpm package. Virtual kernel for use with the Xen emulator package. Configured sources are available in the kernel-xen0-devel-<version>.<arch>.rpm package. Sources for both kernel flavors may be installed at the same time. The files will be installed into the /usr/src/kernels/<version>[-xen0]-<arch>/ tree. Use the command: rpm -Uvh kernel-devel[-xen0]-<version>.<arch>.rpm as appropriate. Following Generic Textbooks Many of the tutorials, examples, and textbooks about Linux kernel development assume the kernel sources are installed under the /usr/src/linux directory. If you make a symbolic link, as shown below, you should be able to use those learning materials with the &FC; packages. Install the appropriate kernel sources, as shown earlier, and then: ln -s /usr/src/kernels/kernel-<all-the-rest> /usr/src/linux
Preparing for Kernel Development &DISTRO; &DISTROVER; does not include the kernel-source package provided by older versions. Instead, configured sources are available as described in . Users that require access to &FC; original kernel sources can find them in the kernel .src.rpm package. To create an exploded source tree from this file, perform the following steps: These Instructions Refer to the Currently-running Kernel! To simplify the following directions, we have assumed that you want to configure the kernel sources to match your currently-running kernel. In the steps below, you must understand that the phrase <version> refers to the kernel version shown by this command: uname -r Obtain the kernel-<version>.src.rpm file from one of the following sources: The SRPMS directory on the appropriate SRPMS CD iso image. The FTP site where you got the kernel package. By running the following command: up2date --get-source kernel Install kernel-<version>.src.rpm using the command: rpm -Uvh kernel-<version>.src.rpm This writes the RPM contents into /usr/src/redhat/SOURCES and /usr/src/redhat/SPECS. Prepare the kernel sources using the commands: cd /usr/src/redhat/SPECS rpmbuild -bp --target $(arch) kernel-2.6.spec The kernel source tree will be located in the /usr/src/redhat/BUILD/kernel-<version> directory. It is common practice to move the resulting linux-<version> directory to the /usr/src tree; while not strictly necessary, we suggest that you do this to match the generally-available documentation. cd /usr/src/redhat/BUILD/kernel-<version> /usr/src/ mv linux-<version> /usr/src/ cd /usr/src ln -s ./linux-<version> linux cd /usr/src/linux The configurations for the specific kernels shipped in &DISTRO; &DISTROVER; are in the configs/ directory. For example, the i686 SMP configuration file is named configs/kernel-<version>-i686-smp.config. Issue the following command to place the desired configuration file in the proper place for building: cp configs/<desired-config-file> .config You can also find the .config file that matches your current kernel configuration in the /lib/modules/<version>/build/.config file. Every kernel gets a name based on its version number. This is the value the uname -r command displays. The kernel name is defined by the first four lines of the kernel Makefile. To protect the innocent, the Makefile has been changed to generate a kernel with a different name from that of the running kernel. Before a module can be accepted by the running kernel, that module must have been compiled for a kernel with the correct name. To do this, you must edit the kernel Makefile For example, if the uname -r returns the string 2.6.11-1.234_FC4, change the EXTRAVERSION definition from this: EXTRAVERSION = -prep to this: EXTRAVERSION = -1.234_FC4 that is, substitute everything from the final dash onward. Issue the following command: make oldconfig You can then proceed as usual.
Building Only Kernel Modules An exploded source tree is not required to build a kernel module, such as your own device driver, against the currently in-use kernel. For example, to build the foo.ko module, create the following Makefile in the directory containing the foo.c file: obj-m := foo.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) default: $(MAKE) -C $(KDIR) M=$(PWD) modules Issue the make command to build the foo.ko module.
User Space Dependencies on the Kernel &DISTRO; adds support for clustered systems. This requires a special kernel that works in conjunction with some user-space utilities, such as management daemons. Consequently, to remove such a kernel, perhaps after an update, you cannot simply use the rpm -e kernel-<version> command as in earlier distributions because these user space packages depend on the kernel package. You may either list both the kernel package and its user space dependent packages on the rpm -e command, or you may wish to use the yum remove kernel-<version> command instead since yum automatically removes dependent packages if necessary.
--- NEW FILE main.xsl --- article nop --- NEW FILE misc-server.xml ---
Miscellaneous Notes This section contains information related to packages that do not fit in any of the preceeding categories.
OpenOffice and upgrading from test releases If you choose to go counter to the recommendation to not upgrade from a previous test release, you may encounter a problem with OpenOffice following the upgrade. To resolve this, you must do the following command before doing the upgrade: rm -rf /usr/lib/openoffice.org*/share/template/*/wizard/bitmap
--- NEW FILE multimedia.xml ---
Multimedia This section contains information related to multimedia applications.
--- NEW FILE networking.xml ---
Networking This section contains information relating to network connectivity.
<filename>NetworkManager</filename> The NetworkManager service allows computers such as laptops to automatically manage changing network connections. It includes support for wireless networking. You must manually enable the NetworkManager service. To do so, type the following in a terminal window: su -c '/sbin/chkconfig --level 345 NetworkManager on; /sbin/service NetworkManager start' su -c '/sbin/chkconfig --level 345 NetworkManagerDispatcher on; /sbin/service NetworkManagerDispatcher start' Enter the root password when prompted. Use the Network Monitor desktop applet to monitor and configure NetworkManager. To load the applet in GNOME, right-click on the panel and select: Add to Panel...Network Monitor NetworkManager uses BIND to proxy DNS requests. Enabling the NetworkManager service also loads the named service as well. By default BIND is configured as a cacheing service for the local system, and does not accept connections from other systems. Note that some wireless network cards require drivers or firmware that cannot be included with &DISTRO;. This software must be installed separately for NetworkManager to function. --- NEW FILE overview.xml ---
Overview of This Release The following list includes brief summaries of some of the more significant aspects of &DISTRO; &DISTROVER;: &DISTRO; &DISTROVER; contains the following changes: Support for the PowerPC (PPC) architecture. GCC 4.0 GNOME 2.10 KDE 3.4 — includes new accessibility features. You can manage these new features in KDS Control CenterRegional & AccessibilityAccessibility. Native Eclipse 3.1M6 (part of a free Java stack) MySQL 4.1 PHP 5.0 Xen 2 (virtualization to run multiple versions of an OS) GFS 6.1-0.pre22 (cluster file system) Evince 0.2.1 (universal document viewer) GDM 2.6 - Includes early login capability &SEL; — This release includes coverage for 80 new daemons by the targeted policy. There are changes to the handling of Booleans. The targeted policy is enabled by default. For more information, refer to: http://fedora.redhat.com/docs/selinux-faq/. This is the complete list of daemons covered by the targeted policy: NetworkManager amanda apache apmd arpwatch auditd bluetooth canna cardmgr checkpolicy chkpwd compat comsat consoletype cpucontrol cpuspeed crond cups cvs cyrus dbskkd dbusd dhcpc dhcpd dictd dmidecode dovecot fingerd fsadm ftpd getty hald hostname hotplug howl hwclock i18n_input ifconfig inetd init initrc innd kerberos klogd ktalkd kudzu ldconfig load_policy login lpd mailman modutil mta mysqld named netutils nscd ntpd portmap postgresql ppd privoxy radius radvd restorecon rlogind rpcd rpm rshd rsync samba saslauthd sendmail setfiles slapd snmpd squid ssh stunnel syslogd telnetd tftpd udev updfstab uucpd webalizer winbind xdm ypbind ypserv zebra
--- NEW FILE package-movement.xml ---
Packages Movement
Packages Moved to &FEX; These are some of the packages that have moved from &CORE; to &FEX;. These are active packages that are maintained and supported by the &FP;. If you are looking for information about &EX;, refer to this URL: http://fedoraproject.org/wiki/Extras List is Incomplete This list highlights some of the major packages that moved from &CORE; to &EX; between &FC; 3 and &FC; &LOCALVER;. This is not a complete list. abiword aiksaurus balsa bzflag cyrus-imapd dbh dietlibc exim freeciv gnuchess gnumeric grip jed lapack libgda libgnomedb libtabe libxfce4mcs libxfce4util libxfcegui Maelstrom ncftp ots recode SDL_image SDL_mixer SDL_net sylpheed system-switch-im xboard xcin xemacs xemacs-sumo xfce4-iconbox [...2192 lines suppressed...] (x86;x86_64) raidtools (x86;x86_64) redhat-java-rpm-scripts (x86;x86_64) rep-gtk (x86_64) samba (i386) (x86;x86_64) sawfish (x86;x86_64) servletapi (x86;x86_64) servletapi-devel (x86;x86_64) shapecfg (x86;x86_64) struts (x86;x86_64) struts-webapps (x86;x86_64) system-config-proc (x86;x86_64) tomcat (x86;x86_64) tomcat-devel (x86;x86_64) tomcat-libs (x86;x86_64) tomcat-test (x86;x86_64) unarj (x86;x86_64) xalan-j (x86;x86_64) xalan-j-devel (x86;x86_64) xalan-j-xsltc (x86;x86_64) xerces-j (x86;x86_64) xerces-j-devel (x86;x86_64) xffm-icons (x86;x86_64) xorg-x11-100dpi-fonts (x86;x86_64) xorg-x11-75dpi-fonts (x86;x86_64) xorg-x11-ISO8859-14-100dpi-fonts (x86;x86_64) xorg-x11-ISO8859-14-75dpi-fonts (x86;x86_64) xorg-x11-ISO8859-15-100dpi-fonts (x86;x86_64) xorg-x11-ISO8859-15-75dpi-fonts (x86;x86_64) xorg-x11-ISO8859-2-100dpi-fonts (x86;x86_64) xorg-x11-ISO8859-2-75dpi-fonts (x86;x86_64) xorg-x11-ISO8859-9-100dpi-fonts (x86;x86_64) xorg-x11-ISO8859-9-75dpi-fonts (x86;x86_64) xorg-x11-base-fonts (x86;x86_64) xorg-x11-cyrillic-fonts (x86;x86_64) xorg-x11-libs-data (x86;x86_64) xorg-x11-syriac-fonts (x86;x86_64) xorg-x11-truetype-fonts
Packages Deprecated The following packages have been deprecated, and may be removed from a future release of &DISTRO;: dbskkd-cdb — Only used by deprecated package skkinput FreeWnn — Only used by deprecated package kinput2-canna-wnn6 (x86) lilo — GRUB is the recommended bootloader miniChinput — IIIMF is the recommended input method nabi — IIIMF is the recommended input method ncpfs — No longer part of &DISTRO; profile skkinput — IIIMF is the recommended input method xcin — IIIMF is the recommended input method
-->
--- NEW FILE package-notes.xml ---
Package-Specific Notes The following sections contain information regarding packages that have undergone significant changes for &DISTRO; &DISTROVER;. For easier access, they are generally organized using the same groups used in Anaconda.
Basic Components This section contains information related to basic system components.
&FEX; Repository &FEX; is part of the larger &FP; and is a volunteer-based community effort to create a repository of packages that compliment &FC;. The &FEX; repository is enabled by default from &FC; &LOCALVER; onwards. You can lean more about &FEX; from: http://fedoraproject.org/wiki/Extras If you would like to install any software available from Fedora extras you can use yum. yum install <packagename> Where <packagename> is the name of the package you want to install. For example, if you wanted to install the abiword package, the command yum install abiword automatically installs the package and all dependencies.
Audit Daemon <command>auditd</command> and Log Files The audit daemon, auditd, is now enabled by default. When auditd is running, the kernel directs audit messages to /var/log/audit/audit.log. The location of this file is specified in /etc/auditd.conf. AVC messages for &SEL; are sent using the audit infrastructure. These messages are now in /var/log/audit/audit.log. When auditd is not running, the kernel passes audit messages to syslog. These logs are typically kept in /var/log/messages and are viewable using dmesg. Audit extensions are now compiled into PAM. All programs that do grant entry to the system or change user account attributes will generate an audit message. To enable auditing within the kernel, you must pass the parameter audit=1 to the kernel during boot. Otherwise, you can use this command to enable auditing during run time: auditctl -e 1
LinuxThreads versus NPTL As the next step in removing support for the obsolete LinuxThreads library, code compiled and linked on &FC; &LOCALVER; now automatically uses the NPTL headers and libraries. In previous releases since &RHL; 9, the default threading was LinuxThreads since the interface is mostly forward compatible. The advantages of the NPTL interface is that the cancellation handling is faster (when -fexception is used, even in C code) and that the additional interfaces are now available without special compiler and linker parameters. In other words, you do not need to use and any longer. Note that lib{,64} is to be interpreted as lib64 on platforms which place DSOs in lib64/ directories, and lib/ otherwise. In &FC; &LOCALVER; it is still possible to create code using the LinuxThreads definitions. For this the linuxthreads-devel package must be installed and must be passed to the compiler. Previously, you could select the version of glibc and the libpgthread DSH using run time environment variables. You now need to also specify this variable in the environment: LD_LIBRARY_PATH=/lib{,64}/obsolete/linuxthreads This additional variable is required because the run/time libraries have been moved out of the way. There may be programs that will not work if the program uses an unfortunate DT_RPATH (which overwrites the LD_LIBRARY_PATH setting). All this makes it more cumbersome to run programs which depend on LinuxThreads. But this is intentional. Important FC5 will not have LinuxThreads support and all programs have to be converted to use NPTL by then. In general, conversion to using NPTL has not been an issue.
Enabling the <filename>slocate</filename> Database The database needed by the locate utility is no longer created by default. Enable the database creation by setting DAILY_UPDATE to in /etc/updatedb.conf if you want to use locate.
Stricter Controls in <filename>openssh</filename> The version of OpenSSH in &FC; &LOCALVER; is based on OpenSSH 3.9 and includes strict permission and ownership checks for the user configuration file ~/.ssh/config. If this file does not have appropriate ownership and permissions, ssh will exit. Check that ~/.ssh/config is owned by the owner of ~/, and that its permissions are set to mode 600. ls -l ~/.ssh/config -rw------- 1 username username 400 May 5 18:44 /home/username/.ssh/config The directory ~/ is command-line shorthand for the logged in user's home directory, usually /home/username/. In addition, OpenSSH is no longer configured to request X11 forwarding by default when connecting to servers. To enable X11 forwarding, the or option must be specified, or the option must be enabled in the ~/.ssh/config file. The behavior of ssh clients that are invoked with the option has changed. In OpenSSH 3.8 and later, X11 forwarding is performed in a way that applications run as untrusted clients by default. Previously, X11 forwarding was performed so that applications always ran as trusted clients. Some applications may not function properly when run as untrusted clients. To forward X11 so that applications are run as trusted clients, invoke ssh with the option instead of the option, or set in the file.
Perl Binary Compat Symlinks Binary compat symlinks for perl-5.8.0, perl-5.8.1, and perl-5.8.2 have been removed. If you have perl modules built with those older versions of perl, you need to rebuild using the perl-5.8.6 contained in &FC; &LOCALVER;.
&SERVER-TOOLS; &JAVA-PACKAGE;
Core This section contains the most elemental components of &DISTRO;, including the kernel.
yum The sqllite database is now used by yum, and makes performance noticeably faster. The Fedora Extras repository is now enabled by default.
&KERNEL; &SECURITY;
&DEVELOPMENT-TOOLS;
Language Support This section includes information related to the support of various languages under &DISTRO;.
The IIIMF Input System IIIMF is the Internet/Intranet Input Method Framework. In &FC; &LOCALVER; the iiimf package is updated to version 12.2. File Path Changes The names and locations of some files in the iiimf packages have changed. The IIIMF server has been renamed from /usr/sbin/htt to /usr/bin/iiimd, and the XIM bridge client renamed from httx to iiimx. The init.d script name has not changed: it is still called iiim. All the global system configuration files are now located under /etc/iiim/. Language Engine (LE) developers should note that LE modules and their data now live under ${libdir}/iiim/le/<LE_NAME>/, while runtime data is stored under /var/lib/iiim/le/<LE_NAME>/. For more information on the exact path and file location changes, please refer to Fedora IIIMF FAQ: http://www.fedora.redhat.com/projects/i18n/iiimf-faq.html. Hotkeys Trigger keys, such as CtrlSpace used to activate Input Methods, are now configurable with the command-line tool iiimf-le-tools. This feature is only supported by GTK2 applications currently. For other applications using XIM the trigger key can be changed using an X resource. Refer to the IIIMF FAQ at http://www.fedora.redhat.com/projects/i18n/iiimf-faq.html for more details on how to change trigger hotkeys. Note that the keyname refers to the X key symbol name. For example, if you want to activate with Ctrl@, you need to specify '<Control>at' as the keyname not '<Control>@'. The per-user configuration of hotkeys does not work currently with &SEL; in enforcing mode due to lack of &SEL; policy. In this case, the hotkey can only be changed in the system-wide configuration. Qt Support A Qt immodule for iiimf is now included. This immodule works but lacks a status window and is considered experimental. Therefore, the default for Qt applications is to continue using XIM for IIMF input. If you wish to try the immodule in a Qt application, first install the iiimf-qt package, start the application, then click mouse button-3 in an input area and select iiimqcf from the Select Input Method' submenu.
&PRINTING; &WEB-SERVERS; &SAMBA; &XORG;
--- NEW FILE printing.xml --- --- NEW FILE project-overview.xml ---
An Overview of the &PROJ; The goal of the &PROJ; is to work with the Linux community to build a complete, general-purpose operating system exclusively from open source software. Development is done in a public forum. The project produces time-based releases of &DISTRO; approximately 2-3 times a year, with a public release schedule. The &RH; engineering team continues to participate in building &DISTRO; and invites and encourages more outside participation than was possible in the past. By using this more open process, we hope to provide an operating system more in line with the ideals of free software and more appealing to the open source community. For more information, refer to the &PROJ; website: http://fedora.redhat.com/ In addition to the website, the following mailing lists are available: fedora-list at redhat.com — For users of &DISTRO; releases fedora-test-list at redhat.com — For testers of &DISTRO; test releases fedora-devel-list at redhat.com — For developers, developers, developers fedora-docs-list at redhat.com — For participants of the Documentation Project To subscribe to any of these lists, send an email with the word "subscribe" in the subject to <listname>-request (where <listname> is one of the above list names.) Alternately, you can subscribe through the Web interface: http://www.redhat.com/mailman/listinfo/ If you have subscribed in the past to rhl-list, rhl-beta-list, rhl-devel-list, or rhl-docs-list, your subscriptions have been retained. The &PROJ; also includes an IRC (Internet Relay Chat) channel. IRC is a real-time, text-based form of communication. With it, you can have conversations with multiple people in an open channel or chat with someone privately one-on-one. To talk with other &PROJ; participants via IRC, access freenode IRC network. Initially, you can use irc.freenode.net as the IRC server, although you may decide to select a server that is geographically closer to you. Refer to the freenode website (http://www.freenode.net/) for more information. &PROJ; participants frequent the #fedora channel, while &PROJ; developers can often be found on the #fedora-devel channel. Some of the larger projects may have their own channels as well; this information can be found on the project pages. In order to talk on the #fedora channel, you will need to register your nickname (nick). Instructions are given when you /join the channel. Note &RH; has no control over the &PROJ; IRC channels or their content.
--- NEW FILE readmes.xsl --- article nop --- NEW FILE samba.xml ---
Samba (Windows File System Compatibility) This section contains information related to Samba, the suite of software that enables Linux to interact with Microsoft Windows systems. Browsing of Windows shares (also known as SMB browsing) fails on &DISTRO; &DISTROVER; systems that have the standard firewall configured. This is most easily noticed in the failure of the desktop to display shares. The firewall disrupts the broadcast mode of SMB browsing, which is the default. There are two workarounds: Configure a WINS server on the network, and set the "wins server" option in smb.conf to the address of the WINS server. Disable the firewall. Disabling the firewall may make your system vulnerable Make sure you fully understand the risks before undertaking this step. For additional information, refer to the following bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133478
--- NEW FILE security.xml ---
Security This section highlights various security items from &FC;.
Digital Certificates Consolidated Digital certificates are now centralised in directories under /etc/pki/. Users performing an upgrade must relocate their digital certificates. OpenSSL: the /usr/share/ssl contents have moved to /etc/pki/tls and /etc/pki/CA. Dovecot: A dovecot-openssl.cnf file is automatically installed in /etc/pki/dovecot/. For information about &SEL;, refer to .
--- NEW FILE server-tools.xml ---
Server and System Configuration Tools This section highlights changes and additions to the various GUI server and system configuration tools in &FC;.
<application>system-config-lvm</application> The new LVM tool system-config-lvm assists you in managing logical volumes.
--- NEW FILE sources --- ### This describes the various package repositories (repos) that up2date will ### query for packages. It currently supports apt-rpm, yum, and "dir" repos. ### Format is one repository (repo) entry per line, # starts comments, the ### first word on each line is the type of repo. ### The default RHN (using "default" as the url means use the one in the ### up2date config file). #up2date default ### Note: when a channel label is required for the non up2date repos, ### the label is solely used as an internal identifier and is not ### based on the url or any other info from the repos. ### An apt style repo (the example is arjan's 2.6 kernel repo). ### The format is: ### type channel-label service:server path repo name #apt arjan-2.6-kernel-i386 http://people.redhat.com ~arjanv/2.5/ kernel ### Note: for apt repos, there can be multiple repo names specified (space ### seperated). ### A yum style repo. The format is: ### type channel-label url yum fedora-core-3 http://download.fedora.redhat.com/pub/fedora/linux/core/3/$ARCH/os/ yum updates-released-fc3 http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/$ARCH/ yum-mirror fedora-core-3 http://fedora.redhat.com/download/up2date-mirrors/fedora-core-3 yum-mirror updates-released-fc3 http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc3 #yum updates-testing http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/3/$ARCH/ #yum-mirror updates-testing http://fedora.redhat.com/download/up2date-mirrors/updates-testing-fc3 #yum development http://download.fedora.redhat.com/pub/fedora/linux/core/development/$ARCH/ #yum-mirror development http://fedora.redhat.com/download/up2date-mirrors/fedora-core-rawhide ### A local directory full of packages (a "dir" repo). For example: #dir my-favorite-rpms /var/spool/RPMS/ # Multiple versions of all repos except "up2date" can be used. Dependencies # can be resolved "cross-repo" if need be. --- NEW FILE splash.xml ---
Welcome to &FC; &LOCALVER; &FC; is a completely free, user friendly, and secure general purpose platform based on Linux. The &FP; is an open source project that pioneers leading edge technology and concepts sponsored by &RH; and supported by the &FED; community. New Installation Guide New for this release is the &FC; &LOCALVER; &IG;. This guide is useful for users of all levels and can be found at this URL: http://fedora.redhat.com/docs/fedora-install-guide-en/ Refer to these webpages to find out more information about &FED;: — Technical release notes Help and Support (http://fedora.redhat.com/participate/communicate/) Participate in the &FP; (http://fedora.redhat.com/participate/) About the &FP; (http://fedora.redhat.com/about/)
New in &FC; &LOCALVER; &FC; &LOCALVER; is the latest version of the free and popular &FC; platform with a number of unique features and significant improvements over previous versions. This section provides an overview of the major highlights in this release. Desktop Enhancements — The &FED; desktop brings to you the latest software such as GNOME 2.10 and KDE 3.4 with a new look and feel. GNOME has the new simple and elegant Clearlooks default theme that is inspired by the classic Red Hat Bluecurve theme, as shown in . New desktop featuring Clearlooks and Evince Screenshot of Fedora desktop showing Firefox in the background and the new universal document viewer Evince in the foreground. Evince is displaying Lawrence Lessig's Free Culture. Improved Productivity Evince (http://www.gnome.org/projects/evince/) is a document viewer for multiple document formats such as pdf, postscript, and many others. Evince replaces a whole category of document viewers with a single simple application. OpenOffice.org 2.0 (http://www.openoffice.org/product2/index.html) is an office productivity suite. This latest version includes several enhancements such as improved Microsoft Office compatibility, completely revamped Impress presentation software, and native support for the OpenDocument format. This version also introduces Base, a fully integrated database management software. You can find the extensive list of new features at http://marketing.openoffice.org/2.0/featureguide.html. Eclipse 3.1 is an open and extensible software development platform that is an Integrated Development Environment (IDE) useful for programming in any language. Support for PowerPC (PPC) Architecture — Refer to and . Improved Security — &SEL; is a security architecture that protects applications and users through finely grained mandatory security controls. The default targeted policy has been improved to cover 80 additional daemons. You can read more in the technical release notes . Integrated Clustering Technology — Global File System (GFS) is an open source clustering file system that allows a cluster of Linux servers to share a common storage pool. &FC; &LOCALVER; has integrated GFS within the system to manage your storage in an efficient way. You can read more at http://www.redhat.com/software/rha/gfs/ and http://www.redhat.com/docs/manuals/enterprise/. Built-in Virtualization — Xen is a virtual machine that can securely run multiple operating systems in their own sandboxed domains. Xen has been integrated into &FC; to work in a seamless fashion. You can read more about Xen at http://fedora.redhat.com/projects/virtualization/. Solid Platform — &FC; &LOCALVER; includes and integrates the latest 4.0 version of GNU Compiler Collection, which has a rewritten optimization infrastructure and improved support for a native open source Java software stack. This stack includes parts of OpenOffice.org 2.0., Eclipse, and Apache Jakarta, among others.
MP3 Codecs and Other Patented or Closed Source Software This section is a brief explanation of why certain software is not included in &FC; or &FEX;. This information was drawn directly from the canonical wiki page: http://fedoraproject.org/wiki/ForbiddenItems A frequent question of the &FP; is why certain items are not included in &FC; or &FEX;. This briefly explains some of the reasons. Other items, such as file systems support, requires community participation. For more information, refer to http://fedoraproject.org/wiki/Wishlist NTFS NTFS Support is not included in the &FC; kernel because of patent concerns. Using a file system natively supported by Linux such as ext3 is a better option. If you must share files between Windows and Linux on a single system, use FAT/FAT32 (vfat) instead. For sharing across a network, Samba is a good option. MP3 encode/decode functionality MP3 support is not included in any &FC; application because MP3 is heavily patented in several regions including the United States. The patent holder is unwilling to give an unrestricted patent grant, as required by the GPL. Other platforms might have paid the royalty and/or included proprietary software. Other Linux distributions not based in a region affected by the patent might ship MP3 decoders/encoders. However, &FC; cannot and does not ship MP3 decoders/encoders in order to serve the goal of shipping only free and open source software. Using other open source formats such as Ogg Vorbis (a lossy codec that has better quality than MP3) or FLAC (a lossless codec) is highly recommended. NVIDIA 3D drivers The NVIDIA 3D drivers are closed source. &FC; does not include proprietary binaries. Consider using an Intel or any other manufacturer that supports open source cards with full specifications and/or source code. ATI 3D drivers The ATI 3D drivers are closed source. &FC; does not include proprietary binaries. Consider using an Intel or any other manufacturer that supports open source cards with full specifications and/or source code. RealPlayer RealPlayer is a closed source application. &FC; does not include proprietary binaries. Consider using open source codecs that do not have patent restrictions. DVD video playback DVD video playback (of CSS encrypted DVDs) may violate the US DMCA (refer to http://en.wikipedia.org/wiki/DMCA) because it may be considered circumventing an encryption mechanism. Additionally, MPEG2 is a patented codec, so even DVDs without encryption cannot be played. Consider using open source unencrypted mediums such as Ogg Theora formats. Mono Mono packages are not currently included due to potential legal issues. (Pending more input.) Applications can be written in other languages that are open source, such as Python, Perl, or Ruby. Java is cross-platform and GCJ is a relatively mature open source implementation of it. These are not direct one-to-one equivalents with .NET but might serve your purpose. Cryptology (mcrypt) Some cryptology related packages such as mcrypt are not included within &FC; due to US export restrictions. Consider using non-restricted cryptographical methods instead. szip The szip license is too restrictive for inclusion in &FEX;. Use other open source alternatives. In conclusion: If it is proprietary, it cannot be included in &FED;. If it is legally encumbered, it cannot be included in &FED;. If it violates US Federal law, it cannot be included in &FED;. Of course, the logical followup is: "But I want to get foo and do bar, how can I do one of the items listed above?" The unofficial http://fedorafaq.org provides useful answers on commonly asked questions. However, these are completely unsupported by the &FP;. The &FP; encourages using free and open source software. The binary only drivers can be acquired from the vendors. You can find many interesting things with Google.
--- NEW FILE web-servers.xml ---
Web Servers This section contains information on Web-related applications.
<filename>mod_perl</filename> The RC5 release of mod_perl 2.0 is now included. The API provided by this release is incompatible with previous 1.99_xx releases. Please refer to the following document for a discussion of how to adapt code to use the new API: http://perl.apache.org/docs/2.0/rename.html
<filename>php</filename> Version 5.0 of PHP is now included, which includes a number of changes to the language along with significant performance improvements. Please refer to the PHP documentation for more information on migrating from PHP 4.3 to PHP 5.0: http://www.php.net/manual/en/migration5.php The /usr/bin/php binary is now built using the CLI command-line SAPI, rather than the CGI SAPI. Use /usr/bin/php-cgi for CGI SAPI. The php-cgi also includes FastCGI support. The following extensions have been added: The mysqli extension, a new interface designed specifically for MySQL 4.1. This is included in the php-mysql package. The soap extension, for implementing SOAP clients and servers. The following extensions are now available as optional loadable extensions, rather than being built in to the PHP binaries: The dba extension, now available in the php-dba package The bcmath extension, now available in the php-bcmath package
--- NEW FILE xorg.xml ---
X Window System (Graphics) This section contains information related to the X Window System implementation provided with &DISTRO;.
<filename>xorg-x11</filename> Users new to the X.org X11 implementation should take note of a few differences between it and the XFree86.org X11 implementation which shipped in previous &RH; and &FED; operating systems. In particular, the names of some files have changed: X Server Binary: XFree86 X11: XFree86 X.org X11: Xorg X Server Configuration File: XFree86 X11: /etc/X11/XF86Config X.org X11: /etc/X11/xorg.conf X Server Log File: XFree86 X11: /var/log/XFree86.$DISPLAY.log X.org X11: /var/log/Xorg.$DISPLAY.log When configuring or troubleshooting your X server configuration, be sure that you are using the correct files. There has been some confusion regarding font-related issues under the X Window System in recent versions of &DISTRO; (and versions of &RHL; before it.) At the present time, there are two font subsystems, each with different characteristics: The original (15+ year old) subsystem is referred to as the core X font subsystem. Fonts rendered by this subsystem are not anti-aliased, are handled by the X server, and have names such as: -misc-fixed-medium-r-normal--10-100-75-75-c-60-iso8859-1 The newer font subsystem is known as fontconfig, and allows applications direct access to the font files. Fontconfig is often used along with the Xft library, which allows applications to render fontconfig fonts to the screen with antialiasing. Fontconfig uses more human-friendly names such as: Luxi Sans-10 Over time, fontconfig and Xft will replace the core X font subsystem. At the present time, applications using the Qt 3 or GTK 2 toolkits (which would include KDE and GNOME applications) use the fontconfig and Xft font subsystem; almost everything else uses the core X fonts. In the future, &FC; may support only fontconfig/Xft in place of the XFS font server as the default local font access method. Note An exception to the font subsystem usage outlined above is OpenOffice.org, which uses its own font rendering technology. The steps to add new fonts to &DISTRO; &DISTROVER; depend on the fonts subsystem this is going to use the new fonts. For the core X font subsystem: Create the /usr/share/fonts/local/ directory (if it doesn't already exist): mkdir /usr/share/fonts/local/ Copy the new font file into /usr/share/fonts/local/ Update the font information by issuing the following commands (note that, due to formatting restrictions, the following commands may appear on more than one line; in use, each command should be entered on a single line): ttmkfdir -d /usr/share/fonts/local/ -o /usr/share/fonts/local/fonts.scale mkfontdir /usr/share/fonts/local/ If you had to create /usr/share/fonts/local/, you must then add it to the X font server (xfs) path: chkfontpath --add /usr/share/fonts/local/ Adding new fonts to the fontconfig font subsystem is more straightforward; the new font file only needs to be copied into the /usr/share/fonts/ directory (individual users can modify their personal font configuration by copying the font file into the ~/.fonts/ directory). After the new font has been copied, use fc-cache to update the font information cache: fc-cache <directory> (Where <directory> would be either the /usr/share/fonts/ or ~/.fonts/ directories.) Individual users may also install fonts graphically, by browsing fonts:/// in Nautilus, and dragging the new font files there. Note If the font filename ends with ".gz", it has been compressed with gzip, and must be decompressed (with the gunzip command) before the fontconfig font subsystem can use the font. Due to the transition to the new font system based on fontconfig/Xft, GTK+ 1.2 applications are not affected by any changes made via the Font Preferences dialog. For these applications, a font can be configured by adding the following lines to the file ~/.gtkrc.mine: style "user-font" { fontset = "<font-specification>" } widget_class "*" style "user-font" (Where <font-specification> represents a font specification in the style used by traditional X applications, such as "-adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-*".)
From fedora-docs-commits at redhat.com Mon Oct 24 13:13:37 2005 From: fedora-docs-commits at redhat.com (Karsten Wade (kwade)) Date: Mon, 24 Oct 2005 09:13:37 -0400 Subject: release-notes/FC4 RELEASE-NOTES-en.xml,1.13,1.14 Message-ID: <200510241313.j9ODDbXG016136@cvs-int.fedora.redhat.com> Author: kwade Update of /cvs/docs/release-notes/FC4 In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16016/FC4 Modified Files: RELEASE-NOTES-en.xml Log Message: EPOCH. Moving all essential release notes XML and related files to the root level for the module. This is done as part of FC5 test1 relnote construction. This is an epoch event because previously versioning was done with unique directories for each release. From this moment forward we are going to use CVS tagging and branching with files all within this directory. Sub-directories are therefore archive directories. It is important to note that this check-in perfectly mirrors the state of FC4 latest release notes, therefore this first check-in shall be tagged as FC4 so that we can return to this point for building FC4 notes in the future. *docs* Index: RELEASE-NOTES-en.xml =================================================================== RCS file: /cvs/docs/release-notes/FC4/RELEASE-NOTES-en.xml,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- RELEASE-NOTES-en.xml 26 Jul 2005 21:07:06 -0000 1.13 +++ RELEASE-NOTES-en.xml 24 Oct 2005 13:13:35 -0000 1.14 @@ -63,10 +63,7 @@ &SPLASH; -
- Legalnotice - &LEGALNOTICE-CONTENT; -
+ &LEGALNOTICE-SECTION; &INTRO; &HARDWARE-REQS; From fedora-docs-commits at redhat.com Mon Oct 24 13:26:50 2005 From: fedora-docs-commits at redhat.com (Karsten Wade (kwade)) Date: Mon, 24 Oct 2005 09:26:50 -0400 Subject: release-notes/css content.css, NONE, 1.1 docbook.css, NONE, 1.1 layout.css, NONE, 1.1 print.css, NONE, 1.1 Message-ID: <200510241326.j9ODQo82016273@cvs-int.fedora.redhat.com> Author: kwade Update of /cvs/docs/release-notes/css In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16224/css Added Files: content.css docbook.css layout.css print.css Log Message: Some additional objects for FC4 and EPOCH. *docs* --- NEW FILE content.css --- .name-project, .name-release, .name-version { } /* Front page H1 */ #page-main h1 { font-size: 1.35em; } #page-main h1.center { text-align: center; } h1, h2, h3, h4 { /* font-style: italic; */ font-family: luxi sans,sans-serif; } h1 { font-size: 1.75em; } h2 { font-size: 1.25em; } h3 { font-size: 1.1em; } hr { border: 0; border-bottom: 1px solid #ccc; } .fedora-side-right-content { padding: 0 5px 1.5em; } #fedora-side-right h1, #fedora-side-right h2, #fedora-side-right h3 { margin: 0; padding: 0 4pt 0; font-size: 1em; letter-spacing: 2pt; border-bottom: 1px solid #bbb; } #fedora-side-right hr { border-bottom: 1px solid #aaa; margin: 0.5em 0; } table tr { font-size: 0.9em; } #link-offsite { } .link-offsite-notation { font-size: 0.9em; color: #777; padding-left: 1pt; text-decoration: none !important; } #fedora-content .link-offsite-notation { color: #999; } #link-redhat { } #fedora-content #link-redhat { } #link-internal { } #fedora-content li { padding: 1pt; } #fedora-content h1 { margin-top: 0; } #fedora-content a img { margin: 1px; border: 0; } #fedora-content a:hover img { margin: 0; border: 1px solid #f00; } #fedora-content a img.noborder { margin: 0; border: 0; } #fedora-content a:hover img .noborder { margin: 0; border: 0; } #fedora-project-maintainers p, #fedora-project-contributors p, #fedora-project-bugs p { margin-left: 5pt; } #fedora-project-download dt { font-weight: bold; margin-top: 8pt; margin-left: 5pt; } #fedora-project-download dd { padding: 0; margin: 10px 20px 0; } #fedora-project-screenshots a img { margin: 5px; } #fedora-project-screenshots a:hover img { margin: 4px; } #fedora-project-todo ul { border: 1px solid #cad4e9; margin: 0 1em; padding: 0; list-style: none; border-radius: 2.5px; -moz-border-radius: 2.5px; } #fedora-project-todo li { margin: 0; padding: 6px 8px; } #fedora-project-todo li.odd { background-color: #ecf0f7; } #fedora-project-todo li.even { background-color: #f7f9fc; } #fedora-list-packages { border-collapse: collapse; border: 1px solid #cad4e9; border-radius: 2.5px; -moz-border-radius: 2.5px; } #fedora-list-packages tr.odd td { background-color: #ecf0f7; } #fedora-list-packages tr.even td { background-color: #f7f9fc; } #fedora-list-packages th, #fedora-list-packages td { margin: 0; padding: 6px 8px; } #fedora-list-packages td.column-2 { text-align: center; } #fedora-list-packages th { background-color: #cad4e9; color: #000; font-weight: bold; text-align: center; } /* pre.screen is for DocBook HTML output */ code.screen, pre.screen { font-family: monospace; font-size: 1em; display: block; padding: 10px; border: 1px solid #bbb; background-color: #eee; color: #000; overflow: auto; border-radius: 2.5px; -moz-border-radius: 2.5px; margin: 0.5em 2em; } #fedora-project code.screen { margin: 0; } code.command, code.filename { font-family: monospace; } code.citetitle { font-family: sans-serif; font-style: italic; } strong.application { font-weight: bold; } .indent { margin: 0 2em; } .fedora-docs-nav { text-align: center; position: relative; padding: 1em; margin-top: 2em; border-top: 1px solid #ccc; } .fedora-docs-nav a { padding: 0 1em; } .fedora-docs-nav-left { position: absolute; left: 0; } .fedora-docs-nav-right { position: absolute; right: 0; } --- NEW FILE docbook.css --- #fedora-content li p { margin: 0.2em; } #fedora-content div.table table { width: 95%; background-color: #DCDCDC; color: #000000; border-spacing: 0; } #fedora-content div.table table th { border: 1px solid #A9A9A9; background-color: #A9A9A9; color: #000000; } #fedora-content div.table table td { border: 1px solid #A9A9A9; background-color: #DCDCDC; color: #000000; padding: 0.5em; margin-bottom: 0.5em; margin-top: 2px; } div.note table, div.tip table, div.important table, div.caution table, div.warning table { width: 95%; border: 2px solid #B0C4DE; background-color: #F0F8FF; color: #000000; /* padding inside table area */ padding: 0.5em; margin-bottom: 0.5em; margin-top: 0.5em; } /* "Just the FAQs, ma'm." */ .qandaset table { border-collapse: collapse; } .qandaset { } .qandaset tr.question { } .qandaset tr.question td { font-weight: bold; padding: 0 0.5em; margin: 0; } .qandaset tr.answer td { padding: 0 0.5em 1.5em; margin: 0; } .qandaset tr.question td, .qandaset tr.answer td { vertical-align: top; } .qandaset strong { text-align: right; } .article .table table { border: 0; margin: 0 auto; border-collapse: collapse; } .article .table table th { padding: 5px; text-align: center; } div.example { padding: 10px; border: 1px solid #bbb; margin: 0.5em 2em; } --- NEW FILE layout.css --- body { font-size: 0.9em; font-family: bitstream vera sans,sans-serif; margin: 0; padding: 0; /* (The background color is specified elsewhere, so do a global replacement if it ever changes) */ background-color: #d9d9d9; } a:link { color: #900; } a:visited { color: #48468f; } a:hover { color: #f20; } a[name] { color: inherit; text-decoration: inherit; } #fedora-header { background-color: #fff; height: 62px; } #fedora-header img { border: 0; vertical-align: middle; } #fedora-header-logo { /* position is offset by the header padding amount */ position: absolute; left: 26px; top: 13px; z-index: 3; } #fedora-header-logo img { width: 110px; height: 40; } #fedora-header-items { /* position is offset by the header padding amount */ position: absolute; right: 10px; top: 15px; text-align: right; display: inline; } #fedora-header-items a { color: #000; text-decoration: none; padding: 7pt; font-size: 0.8em; } #fedora-header-items a:hover, #fedora-header-search-button:hover { color: #f20; cursor: pointer; } #fedora-header-items img { margin-right: 1px; width: 36px; height: 36px; } #fedora-header-search { height: 25px; } #fedora-header-search-entry { vertical-align: top; margin: 0.65em 4px 0 10px; padding: 2px 4px; background-color: #f5f5f5; border: 1px solid #999; font-size: 0.8em !important; } #fedora-header-search-entry:focus { background-color: #fff; border: 1px solid #555; } #fedora-header-search-button { font-size: 0.8em !important; vertical-align: top; margin-top: 0.2em; border: 0; padding: 7px; background: #fff url('../img/header-search.png') no-repeat left; padding-left: 21px; } #fedora-header-items form { float: right; } #fedora-header-items input { font-size: 0.85em; } #fedora-nav { margin: 0; padding: 0; background-color: #22437f; font-size: 0; height: 5px; border-top: 1px solid #000; border-bottom: 1px solid #f5f5f5; } #fedora-nav ul { margin: 0; padding: 0; } #fedora-nav li { display: inline; list-style: none; padding: 0 5pt; } #fedora-nav li + li { padding-left: 8pt; border-left: 1px solid #99a5bf; } #fedora-nav a { color: #c5ccdb; text-decoration: none; } #fedora-nav a:hover { color: #fff; } #fedora-side-left { position: absolute; z-index: 2; width: 11em; /* Space down for the approx line height (fonts) */ left: 12px; } #fedora-side-right { position: absolute; z-index: 1; width: 13em; right: 12px; padding-top: 3px; } #fedora-side-left, #fedora-side-right { top: 2px; /* add to the top margin to compensate for the fixed sizes */ margin-top: 75px; color: #555; font-size: 0.9em; } #fedora-side-right ul { list-style: square inside; padding: 0; margin: 0; } /* Left-side naviagation */ #fedora-side-nav-label { display: none; } #fedora-side-nav { list-style: none; margin: 0; padding: 0; border: 1px solid #5976b2; border-top: 0; background-color: #22437f; } #fedora-side-nav li { margin: 0; padding: 0; border-top: 1px solid #5976b2; /* IE/Win gets upset if there is no bottom border... Go figure. */ border-bottom: 1px solid #22437f; } #fedora-side-nav a { margin: 0; color: #c5ccdb; display: block; text-decoration: none; padding: 4px 6px; } #fedora-side-nav a:hover { background-color: #34548f; color: #fff; } #fedora-side-nav ul { list-style: none; margin: 0; padding: 0; } #fedora-side-nav ul li { border-top: 1px solid #34548e; background-color: #34548e; /* IE/Win gets upset if there is no bottom border... Go figure. */ border-bottom: 1px solid #34548e; } #fedora-side-nav ul li:hover { border-bottom: 1px solid #34548f; } #fedora-side-nav ul li a { padding-left: 12px; color: #a7b2c9; } #fedora-side-nav ul li a:hover { background-color: #46659e; } #fedora-side-nav ul ul li a { padding-left: 18px; } #fedora-side-nav strong a { font-weight: normal; color: #fff !important; background-color: #10203b; } #fedora-side-nav strong a:hover { background-color: #172e56 !important; } /* content containers */ #fedora-middle-one, #fedora-middle-two, #fedora-middle-three { font-size: 0.9em; /* position: relative; */ /* relative to utilize z-index */ width: auto; min-width: 120px; margin: 10px; z-index: 3; /* content can overlap when the browser is narrow */ } #fedora-middle-two, #fedora-middle-three { margin-left: 11em; padding-left: 24px; } #fedora-middle-three { margin-right: 13em; padding-right: 24px; } #fedora-content { padding: 24px; border: 1px solid #aaa; background-color: #fff; } #fedora-content > .fedora-corner-bottom { top: 0 } .fedora-corner-tl, .fedora-corner-tr, .fedora-corner-bl, .fedora-corner-br { background-color: #d9d9d9; position: relative; width: 19px; height: 19px; /* The following line is to render PNGs with alpha transparency within IE/Win, using DirectX */ /* Work-around for IE6/Mac borkage (Part 1) */ display: none; } .fedora-corner-tl, .fedora-corner-bl { float: left; left: 0px; } .fedora-corner-tr, .fedora-corner-br { float: right; right: 0px; } .fedora-corner-tl, .fedora-corner-tr { top: 0px; } .fedora-corner-bl, .fedora-corner-br { bottom: 0px; margin-top: -19px; /* Opera fix (part 1) */ top: -18px;} html>body .fedora-corner-tl { background: #d9d9d9 url("../img/corner-tl.png") no-repeat left top; } html>body .fedora-corner-tr { background: #d9d9d9 url("../img/corner-tr.png") no-repeat right top; } html>body .fedora-corner-bl { background: #d9d9d9 url("../img/corner-bl.png") no-repeat left bottom; } html>body .fedora-corner-br { background: #d9d9d9 url("../img/corner-br.png") no-repeat right bottom; } .fedora-corner-tl { filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='/img/corner-tl.png',sizingMethod='scale'); } .fedora-corner-tr { filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='/img/corner-tr.png',sizingMethod='scale'); } .fedora-corner-br { filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='/img/corner-br.png',sizingMethod='scale'); } .fedora-corner-bl { filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='/img/corner-bl.png',sizingMethod='scale'); } /* \*/ .fedora-corner-tl, .fedora-corner-tr, .fedora-corner-bl, .fedora-corner-br { /* Restore the view for everything but IE6/Mac (part 2 of the "IE/Mac fix") */ display: block; } /* */ .fedora-corner-bl, .fedora-corner-br { top: 0px; } .content { margin: 0 1em } #fedora-sidelist { position: relative; bottom: 3px; margin: 0; padding: 3px !important; border: 1px solid #bbb; background-color: #ccc; border-radius: 2.5px; -moz-border-radius: 2.5px; } #fedora-sidelist strong a { font-weight: normal; background-color: #555; color: #fff; } #fedora-sidelist strong a:hover { background-color: #333; color: #fff; } #fedora-sidelist li { list-style-position: outside; font-size: 0.9em; list-style: none; border: 1px solid #ccc; border-width: 1px 0; padding: 0; list-style: none; } #fedora-sidelist li a { text-decoration: none; display: block; padding: 6px 8px; border-radius: 2.5px; -moz-border-radius: 2.5px; } #fedora-sidelist li a:hover { background-color: #999; color: #eee; } #fedora-footer { font-size: 0.75em; text-align: center; color: #777; margin-bottom: 2em; } #fedora-printable { text-align: center; margin: 1em 0; font-size: 0.85em; } #fedora-printable a { text-decoration: none; padding: 5px 0; padding-left: 18px; background: transparent url("../img/printable.png") no-repeat left; } #fedora-printable a:hover { text-decoration: underline; } --- NEW FILE print.css --- body { background: white; color: black; font-size: 10pt; font-family: sans-serif; line-height: 1.25em; } div { border: 1px solid white; } li { border: 1px solid white; margin: 0; } li p { display: inline; } h1 { font-size: 16pt; } h2 { font-size: 12pt; } h3,h4,h5 { font-size: 10pt; } img { border: 1px solid white; background-color: white; } hr { border: 1px dotted gray; border-width: 0 0 1 0; margin: 1em; } table { border-collapse: collapse; } td,th { border: 1px solid gray; padding: 8pt; font-size: 10pt; } th { font-weight: bold; } #fedora-header, #fedora-footer { text-align: center; } #fedora-header-items, #fedora-side-left, #fedora-side-right { display: none; } #fedora-project-download dt { font-weight: bold; margin-top: 8pt; margin-left: 5pt; } #fedora-project-download dd { padding: 0; margin: 10px 20px 0; } code.screen, pre.screen { font-family: monospace; font-size: 1em; display: block; padding: 5pt; border: 1px dashed gray; margin: 0.5em 2em; } #fedora-project code.screen { margin: 0; } /* #fedora-content a:link:after, #fedora-content a:visited:after { content: " (" attr(href) ") "; font-size: 80%; } */ .navheader table, .navheader table td { border: 0 !important; } From fedora-docs-commits at redhat.com Mon Oct 24 13:26:51 2005 From: fedora-docs-commits at redhat.com (Karsten Wade (kwade)) Date: Mon, 24 Oct 2005 09:26:51 -0400 Subject: release-notes/figs Fedora_Desktop.eps, NONE, 1.1 Fedora_Desktop.png, NONE, 1.1 Message-ID: <200510241326.j9ODQpAM016278@cvs-int.fedora.redhat.com> Author: kwade Update of /cvs/docs/release-notes/figs In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16224/figs Added Files: Fedora_Desktop.eps Fedora_Desktop.png Log Message: Some additional objects for FC4 and EPOCH. *docs* --- NEW FILE Fedora_Desktop.eps --- %!PS-Adobe-3.0 EPSF-3.0 %%Creator: (ImageMagick) %%Title: (Fedora_Desktop.eps) %%CreationDate: (Fri Jun 3 15:31:48 2005) %%BoundingBox: 0 0 113 85 %%HiResBoundingBox: 0 0 113.386 85 %%DocumentData: Clean7Bit %%LanguageLevel: 1 %%Pages: 1 %%EndComments %%BeginDefaults %%EndDefaults %%BeginProlog % % Display a color image. The image is displayed in color on % Postscript viewers or printers that support color, otherwise % it is displayed as grayscale. % /DirectClassPacket { % % Get a DirectClass packet. % % Parameters: % red. % green. % blue. % length: number of pixels minus one of this color (optional). % currentfile color_packet readhexstring pop pop compression 0 eq { /number_pixels 3 def } { currentfile byte readhexstring pop 0 get /number_pixels exch 1 add 3 mul def } ifelse 0 3 number_pixels 1 sub { pixels exch color_packet putinterval } for pixels 0 number_pixels getinterval } bind def /DirectClassImage { % % Display a DirectClass image. % systemdict /colorimage known { columns rows 8 [ columns 0 0 rows neg 0 rows ] { DirectClassPacket } false 3 colorimage } { % % No colorimage operator; convert to grayscale. % columns rows 8 [ columns 0 0 rows neg 0 rows ] { GrayDirectClassPacket } image } ifelse } bind def /GrayDirectClassPacket { % % Get a DirectClass packet; convert to grayscale. % % Parameters: % red % green % blue % length: number of pixels minus one of this color (optional). % currentfile color_packet readhexstring pop pop color_packet 0 get 0.299 mul color_packet 1 get 0.587 mul add color_packet 2 get 0.114 mul add cvi /gray_packet exch def compression 0 eq { /number_pixels 1 def } { currentfile byte readhexstring pop 0 get /number_pixels exch 1 add def } ifelse 0 1 number_pixels 1 sub { pixels exch gray_packet put } for pixels 0 number_pixels getinterval } bind def /GrayPseudoClassPacket { % % Get a PseudoClass packet; convert to grayscale. % % Parameters: % index: index into the colormap. % length: number of pixels minus one of this color (optional). % currentfile byte readhexstring pop 0 get /offset exch 3 mul def /color_packet colormap offset 3 getinterval def color_packet 0 get 0.299 mul color_packet 1 get 0.587 mul add color_packet 2 get 0.114 mul add cvi /gray_packet exch def compression 0 eq { /number_pixels 1 def } { currentfile byte readhexstring pop 0 get /number_pixels exch 1 add def } ifelse 0 1 number_pixels 1 sub { pixels exch gray_packet put } for pixels 0 number_pixels getinterval } bind def /PseudoClassPacket { % % Get a PseudoClass packet. % % Parameters: % index: index into the colormap. % length: number of pixels minus one of this color (optional). % currentfile byte readhexstring pop 0 get /offset exch 3 mul def /color_packet colormap offset 3 getinterval def compression 0 eq { /number_pixels 3 def } { currentfile byte readhexstring pop 0 get /number_pixels exch 1 add 3 mul def } ifelse 0 3 number_pixels 1 sub { pixels exch color_packet putinterval } for pixels 0 number_pixels getinterval } bind def /PseudoClassImage { % % Display a PseudoClass image. % % Parameters: % class: 0-PseudoClass or 1-Grayscale. % currentfile buffer readline pop token pop /class exch def pop class 0 gt { currentfile buffer readline pop token pop /depth exch def pop /grays columns 8 add depth sub depth mul 8 idiv string def columns rows depth [ columns 0 0 rows neg 0 rows ] { currentfile grays readhexstring pop } image } { % % Parameters: % colors: number of colors in the colormap. % colormap: red, green, blue color packets. % currentfile buffer readline pop token pop /colors exch def pop /colors colors 3 mul def /colormap colors string def currentfile colormap readhexstring pop pop systemdict /colorimage known [...15505 lines suppressed...] 8F8F8EA9A8A7ABABAA40403F625F5DC8C2BDCBC5C0CBC5C0CBC5C0CBC5C0323130B9B3AE CBC5C0CBC5C0CAC4BF393836BDB7B28E898653504E7D7A778A8582AFAAA54C4A4873706D 7E7A77B0ABA6CBC5C0CBC5C0BEB8B35A5855514F4D716E6B66636098938FCAC4BF373634 64615E2F2E2C84817D393836CAC4BF5A5755827E7B9F9B973D3B396A67642B2A28B0ACA7 403E3CB7B2AD9C98934F4C4A7C787686817EBBB5B0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0 CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0 CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0 CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0 CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0 CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0CBC5C0A09A94E0DCD7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7BFB7AFEBE7E2E5DFD9E4DED8E3DDD7C3BEB9908E8BA09F9E D2D1D0CDCCCB878583C0BBB6E0DAD4E4DED8E5DFD9E4DED8E5DFD9E3DDD6B8AEA4EFEBE7 E6E1DBD6CFC7D7CFC7ECE8E3EFEBE7BFB7AFEBE7E2E5DFD9E5DFD9E4DED8E2DDD7AAA49F 5B43414A1F1D4E221B4B3428857E79D5CFC9E5DFD9E5DFD9E5DFD9E5DFD9E5DFD9D8D2CC C5C0BBE5DFD9E5DFD9E5DFD9E3DDD7CCC7C1B2AEA9B9B5B0DCD6D1CBC6C0B4B0ABC6C0BB CFCAC4E1DBD5BFBAB5B4AFAAD2CDC7DED8D2C4BFBAE3DDD7CFCAC4B3AFAACAC5BFB8B4AF DFD9D3E5DFD9E5DFD9C1BCB7DCD6D0E5DFD9E5DFD9E5DFD9DED8D3C4BFBAE3DDD7E0DAD4 B9B4B0B6B1ADD4CEC9898582979490E2DCD7C6C1BCB2AEA9BEB9B4DED8D3D1CBC6B4B0AB B9B4AFE0DAD4D5CFCABDB8B4CFCAC4716E6CD8D2CDE5DFD9E5DFD9DAD5CFB7B2ADB4B0AB CDC8C2E4DED85553519C9894BAB6B1DAD5CFE2DCD6C4BFBAB3AFAACCC7C1E4DED8BFBAB5 E1DBD6CAC5C0D3CEC8C7C2BDB2AEA9BCB7B3DED9D3E3DDD7C9C4BFB3AEAAC6C1BCE4DED8 C0BBB6E0DAD4E2DCD7C6C1BCB2AEA9BEB9B4DED8D3C5C0BAB8B4AFC1BCB7D6D0CBDCD7D1 C4BFBAE5DFD9CAC5C0D6D0CBE5DFD9BEB9B5E1DBD6E5DFD9E5DFD9E5DFD9C7BDB4887F77 C5BDB4CAC4BECAC4BEB2ADA98B88868B888683807E817F7C8886838A888689868461605D 3E3D3C817D7ACAC4BECAC4BECAC4BECAC4BEA49F9AC6C0BACAC4BECAC4BECAC4BEA6A19C C7C1BBC7C1BBA8A39E9A9591A9A49FC5BFB9B6B0AB9C97929D9894C0BAB5CAC4BECAC4BE CAC4BEC0BBB5A09B97999490A29D99C0BBB5CAC4BEA8A39EA29D98ABA6A1B8B3AEA6A19C CAC4BEB5AFAAA8A39EC1BCB6A29D98ABA6A1A6A19DC4BEB8A7A29EC5BFBAC8C2BCADA8A3 9A9591A5A09BC4BEB8CAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BE CAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BE CAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BE CAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BE CAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BECAC4BE CAC4BECAC4BECAC4BECAC4BECAC4BEA09A94E0DCD7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 C1B8B0EBE6E1E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7 E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E3DCD6B9AFA5EFEBE7E9E4DFDED8D1DED8D1EDE9E4 EFEBE7C1B8B0EBE6E1E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7 E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7 E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7 E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7 E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E2DCD6ABA6A262605E B8B3AEE4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7 DAD4CEB5B0ACE2DCD6E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7837F7CD1CBC5 E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7 E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7 E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7 E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7E4DDD7C8BEB5898078C4BCB3C9C3BDC9C3BDC9C3BD C7C1BCC7C1BCC7C1BCC7C1BCC7C1BCC7C1BCC7C1BCC4BEB99B97929A9591C9C3BDC9C3BD C9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BD C9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BD C9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BD C9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BD C9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BD C9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BD C9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BD C9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BD C9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BDC9C3BD C9C3BDA09A94E0DCD7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7C2B9B1E4DED8E3DCD6E3DCD6 E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6 E3DCD6DAD2CBC1B8AFEFEBE7EBE7E3E6E1DCE6E1DCEEEAE6EFEBE7C2B9B1E4DED8E3DCD6 E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6 E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6 E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6 E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6 E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD5D6CFC9D0C9C4E0D9D3E3DCD6E3DCD6E3DCD6 E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD5E3DCD5E3DCD6E3DCD6 E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6DCD5CFE2DBD4E3DCD6E3DCD6E3DCD6E3DCD6 E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6 E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6 E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6E3DCD6 E3DCD6E3DCD6C3BAB0999189BBB3ABC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BC C8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BC C8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BC C8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BC C8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BC C8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BC C8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BC C8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BC C8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BC C8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BC C8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC8C2BCC5BFB9A19A94E3DEDAEFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7D9D2CBBBB0A5B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2 B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2BDB3A9E4DFD9EFEBE7 E8E3DEDDD7D0DDD7D0EDE8E4EFEBE7D9D2CBBBB0A5B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2 B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2 B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2 B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2 B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2 B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2 B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2 B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2 B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2 B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2 B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2B8ADA2D0C8C0DCD8D3 A19B95969089969089969089969089969089969089969089969089969089969089969089 969089969089969089969089969089969089969089969089969089969089969089969089 969089969089969089969089969089969089969089969089969089969089969089969089 969089969089969089969089969089969089969089969089969089969089969089969089 969089969089969089969089969089969089969089969089969089969089969089969089 969089969089969089969089969089969089969089969089969089969089969089969089 969089969089969089969089969089969089969089969089969089969089969089969089 969089969089969089969089969089969089969089969089969089969089969089969089 969089969089969089969089969089969089969089969089969089969089969089969089 969089969089969089969089969089969089969089969089969089969089969089969089 96908996908996908996908998938CC7C2BDEDE9E5EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7EFEBE7 end %%PageTrailer %%Trailer %%EOF From fedora-docs-commits at redhat.com Mon Oct 24 13:26:56 2005 From: fedora-docs-commits at redhat.com (Karsten Wade (kwade)) Date: Mon, 24 Oct 2005 09:26:56 -0400 Subject: release-notes/img corner-bl.png, NONE, 1.1 corner-br.png, NONE, 1.1 corner-tl.png, NONE, 1.1 corner-tr.png, NONE, 1.1 header-download.png, NONE, 1.1 header-faq.png, NONE, 1.1 header-fedora_logo.png, NONE, 1.1 header-projects.png, NONE, 1.1 Message-ID: <200510241326.j9ODQuLd016291@cvs-int.fedora.redhat.com> Author: kwade Update of /cvs/docs/release-notes/img In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16224/img Added Files: corner-bl.png corner-br.png corner-tl.png corner-tr.png header-download.png header-faq.png header-fedora_logo.png header-projects.png Log Message: Some additional objects for FC4 and EPOCH. *docs* From fedora-docs-commits at redhat.com Mon Oct 24 13:33:25 2005 From: fedora-docs-commits at redhat.com (Karsten Wade (kwade)) Date: Mon, 24 Oct 2005 09:33:25 -0400 Subject: release-notes RELEASE-NOTES-en.xml,1.1,1.2 Message-ID: <200510241333.j9ODXPV0016357@cvs-int.fedora.redhat.com> Author: kwade Update of /cvs/docs/release-notes In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16338 Modified Files: RELEASE-NOTES-en.xml Log Message: Checking this in to repair the build, otherwise it is broken looking for a non-existent relative path. Ick. Index: RELEASE-NOTES-en.xml =================================================================== RCS file: /cvs/docs/release-notes/RELEASE-NOTES-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- RELEASE-NOTES-en.xml 24 Oct 2005 13:13:33 -0000 1.1 +++ RELEASE-NOTES-en.xml 24 Oct 2005 13:33:23 -0000 1.2 @@ -31,9 +31,9 @@ - + %FEDORA-ENTITIES-EN; - + From fedora-docs-commits at redhat.com Mon Oct 24 13:56:51 2005 From: fedora-docs-commits at redhat.com (Karsten Wade (kwade)) Date: Mon, 24 Oct 2005 09:56:51 -0400 Subject: docs-common/common legalnotice-section-en.xml, NONE, 1.1 fedora-entities-en.ent, 1.10, 1.11 legalnotice-relnotes-en.xml, 1.2, 1.3 Message-ID: <200510241356.j9ODupJ4016488@cvs-int.fedora.redhat.com> Author: kwade Update of /cvs/docs/docs-common/common In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16466 Modified Files: fedora-entities-en.ent legalnotice-relnotes-en.xml Added Files: legalnotice-section-en.xml Log Message: Must have forgotten to add these pieces when I did the legalnotice tricks for FC4, that move the bulk of the notes into a separate section with only a pointer in the container. *docs* --- NEW FILE legalnotice-section-en.xml ---
Legalnotice &LEGALNOTICE-CONTENT;
Index: fedora-entities-en.ent =================================================================== RCS file: /cvs/docs/docs-common/common/fedora-entities-en.ent,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- fedora-entities-en.ent 18 Oct 2005 21:48:03 -0000 1.10 +++ fedora-entities-en.ent 24 Oct 2005 13:56:48 -0000 1.11 @@ -49,6 +49,7 @@ + Index: legalnotice-relnotes-en.xml =================================================================== RCS file: /cvs/docs/docs-common/common/legalnotice-relnotes-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- legalnotice-relnotes-en.xml 19 Jul 2005 20:41:03 -0000 1.2 +++ legalnotice-relnotes-en.xml 24 Oct 2005 13:56:48 -0000 1.3 @@ -7,6 +7,19 @@ ]> --> + + + This document is released under the terms of the GNU Free Documentation License. For more details, read the full legalnotice in Author: kwade Update of /cvs/docs/release-notes In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv17937 Modified Files: Makefile Log Message: Need to find a way to do this better, and I think it should be in the Makefile.common instead. However, my method here is obviously sub-par and throws an error, so I'll be punting for help. The objective is to make certain that the figs/ directory gets copied over to the HTML directories in all languages. Actually, the figs-/ needs to get copied to foo-/ HTML directory. This requires some consideration and kung-fu. It should copy over the language specific figures if they exist, otherwise use the English by default so as to not break the build. Index: Makefile =================================================================== RCS file: /cvs/docs/release-notes/Makefile,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Makefile 24 Oct 2005 13:13:33 -0000 1.1 +++ Makefile 24 Oct 2005 14:08:53 -0000 1.2 @@ -1,90 +1,100 @@ -LANG = en -DOCS_SETUP_PATH= ../../docs-common -XSLPDF = $(DOCS_SETUP_PATH)/xsl/main-pdf.xsl -XSLHTML = $(DOCS_SETUP_PATH)/xsl/main-html-nochunks-relnotes.xsl - -XSLPDFCOMMONS = ${XSLPDF} -XSLHTMLCOMMONS = ${XSLHTML} - -XMLCOMMONSPATH=${DOCS_SETUP_PATH}/common -XMLCOMMONS=${XMLCOMMONSPATH}/cvs-en.xml \ - ${XMLCOMMONSPATH}/draftnotice-en.xml \ - ${XMLCOMMONSPATH}/fedora-entities-en.ent \ - ${XMLCOMMONSPATH}/fedora-entities-en.xml \ - ${XMLCOMMONSPATH}/legacynotice-en.xml \ - ${XMLCOMMONSPATH}/legalnotice-en.xml \ - ${XMLCOMMONSPATH}/obsoletenotice-en.xml - -.SUFFIXES: -.SUFFIXES: .html .pdf .xml - -all: README-${LANG}.html \ - RELEASE-NOTES-${LANG}.html \ - RELEASE-NOTES-${LANG}.txt \ - README-${LANG}.txt - -#README-${LANG}.pdf RELEASE-NOTES-${LANG}.pdf - -%.pdf: %.xml - xmlto pdf -x ${XSLPDF} $< - -%.html: %.xml - ${RM} -r ${@:.html=} - xmlto html -x ${XSLHTML} -o ${@:.html=} $< - mkdir -p ${@:.html=}/stylesheet-images - mkdir -p ${@:.html=}/figs - cp $(DOCS_SETUP_PATH)/stylesheet-images/*.png ${@:.html=}/stylesheet-images - cp ./figs/*.png ${@:.html=}/figs - cp $(DOCS_SETUP_PATH)/css/fedora.css ${@:.html=} - mv ${@:.html=}/${@:.html=.proc} ${@:.html=}/$@ - ln -sf ${@:.html=}/$@ $@ - -%.txt: %.xml - xmlto txt $< -# mv $@ RELEASE-NOTES-${LANG} - -# FIXME eula.txt: eula.py -# FIXME python -c "import py_compile; py_compile.compile('eula.py')" - -# Note: keep "RELEASE-NOTES-en.xml" first, for now. - -RNFILES=RELEASE-NOTES-en.xml daemons.xml database-servers.xml \ - desktop.xml development-tools.xml feedback.xml file-servers.xml \ - file-systems.xml hardware-reqs.xml install-notes.xml intro.xml \ - java-package.xml kernel.xml misc-server.xml multimedia.xml \ - networking.xml overview.xml package-movement.xml \ - package-notes.xml printing.xml project-overview.xml samba.xml \ - security.xml server-tools.xml splash.xml web-servers.xml \ - xorg.xml - -# README-${LANG}.pdf: README-en.xml -# README-${LANG}.html: README-en.xml -RELEASE-NOTES-${LANG}.pdf: ${RNFILES} ${XMLCOMMONS} ${XSLPDFCOMMONS} -RELEASE-NOTES-${LANG}.html: ${RNFILES} ${XMLCOMMONS} ${XSLHTMLCOMMONS} -RELEASE-NOTES-${LANG}.txt: ${RNFILES} ${XMLCOMMONS} - -clean: - ${RM} ChangeLog ChangeLog.xml - -distclean clobber: clean - ${RM} ChangeLog-${LANG}.html ChangeLog.txt - ${RM} -r README-${LANG}.pdf README-${LANG}.html README-${LANG}.txt - ${RM} -r RELEASE-NOTES-${LANG}.pdf RELEASE-NOTES-${LANG}.html \ - RELEASE-NOTES-${LANG} RELEASE-NOTES-${LANG}.txt - -# If you have the "cvs2cl" package installed, then you can make -# fancy HTML ChangeLogs - -ChangeLogs: - ${RM} ChangeLog* - ${MAKE} ChangeLog.txt - ${MAKE} ChangeLog-${LANG}.html - -ChangeLog.txt: - LANG=C cvs2cl -f ChangeLog.txt - -ChangeLog.xml: - LANG=C cvs2cl --xml --xml-encoding UTF-8 -f ChangeLog.xml - -ChangeLog-${LANG}.html: ChangeLog.xml - xsltproc -o $@ /usr/share/xml/cvs2cl/cl2html.xslt $< +############################################################################### +# Makefile for RHLP docs project +# Created by: Tammy Fox +# Last edited by: Tommy Reynolds +# WARNING: need passivetex 1.24 for pdf generation to work +# License: GPL +# Copyright 2003 Tammy Fox, Red Hat, Inc. +# Copyright 2005 Tommy Reynolds, MegaCoder.com +############################################################################### +# +# Document-specific definitions. +# +LANGUAGES = en +DOCBASE = RELEASE-NOTES +XMLEXTRAFILES-en=daemons.xml database-servers.xml desktop.xml development-tools.xml feedback.xml file-servers.xml file-systems.xml hardware-reqs.xml install-notes.xml intro.xml java-package.xml kernel.xml misc-server.xml multimedia.xml networking.xml overview.xml package-movement.xml package-notes.xml printing.xml project-overview.xml samba.xml security.xml server-tools.xml splash.xml web-servers.xml xorg.xml +# +###################################################### +include ../docs-common/Makefile.common +###################################################### +# +# If you want to add additional steps to any of the +# targets defined in "Makefile.common", be sure to use +# a double-colon in your rule here. For example, to +# print the message "FINISHED AT LAST" after building +# the HTML document version, uncomment the following +# line: +#${DOCBASE}-en/index.html:: +# echo FINISHED AT LAST + +# Need to copy over the figures for this directory. Should +# this be a common action instead? +${DOCBASE}-en/index.html:: + mkdir -p ${DOCBASE}-${LANGUAGES}/figs + cp figs/* ${DOCBASE}-${LANGUAGES}/figs + +###################################################### +# Some packaging specific vars +VERSION=$(shell grep BOOKID $(DOCBASE)-en.xml | sed 's/ - $(VERSION)-1\n- Update to version $(VERSION)\n/' \ + $(SPECIN) > $(DOCSPEC) +# +# Fill in files +# FIXME: Needs to be multiplexed for LANGUAGES (see above) + cp $(OMFIN) $(DOCOMF) + cp $(DESKTOPIN) $(DOCDESKTOP) + sed -i 's/@VERSION@/$(VERSION)/g' $(DOCOMF) + sed -i 's/@DATE@/$(DATE)/g' $(DOCOMF) + sed -i 's/@TITLE@/$(TITLE)/g' $(DOCOMF) + sed -i 's/@DOCBASE@/$(DOCBASE)/g' $(DOCOMF) + sed -i 's/@VERSION@/$(VERSION)/g' $(DOCDESKTOP) + sed -i 's/@DATE@/$(DATE)/g' $(DOCDESKTOP) + sed -i 's/@TITLE@/$(TITLE)/g' $(DOCDESKTOP) + sed -i 's/@DOCBASE@/$(DOCBASE)/g' $(DOCDESKTOP) +# +# Do the build... +# + rpmbuild -bb $(RPMFLAGS) $(DOCSPEC) + mv RPMS/noarch/*.rpm . + rpmbuild --clean --rmsource $(RPMFLAGS) $(DOCSPEC) + rm -rf {BUILD,RPMS,SOURCES,SPECS,SRPMS} + rm -rf $(DOCBASE)-$(VERSION) From fedora-docs-commits at redhat.com Mon Oct 24 14:16:40 2005 From: fedora-docs-commits at redhat.com (Karsten Wade (kwade)) Date: Mon, 24 Oct 2005 10:16:40 -0400 Subject: docs-common/common legalnotice-relnotes-en.xml,1.3,1.4 Message-ID: <200510241416.j9OEGeaC018026@cvs-int.fedora.redhat.com> Author: kwade Update of /cvs/docs/docs-common/common In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv18007/docs-common/common Modified Files: legalnotice-relnotes-en.xml Log Message: This provides a very prominent link that appears above the fold in the relnotes nochunks version. A similar tip is at the top of the splash.xml page. When displayed as the default Firefox homepage, this nochunks version fulfills the promise of giving direct access to an updated release notes. Index: legalnotice-relnotes-en.xml =================================================================== RCS file: /cvs/docs/docs-common/common/legalnotice-relnotes-en.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- legalnotice-relnotes-en.xml 24 Oct 2005 13:56:48 -0000 1.3 +++ legalnotice-relnotes-en.xml 24 Oct 2005 14:16:38 -0000 1.4 @@ -21,8 +21,17 @@ --> - This document is released under the terms of the GNU Free Documentation + + This document is released under the terms of the GNU Free Documentation License. For more details, read the full legalnotice in . + linkend="sn-legalnotice" />. + + Latest Release Notes on the Web + + These release notes may be updated. Visit http://fedora.redhat.com/docs/release-notes/ + to view the latest release notes for &DISTRO; &DISTROVER;. + + From fedora-docs-commits at redhat.com Mon Oct 24 20:34:36 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 24 Oct 2005 16:34:36 -0400 Subject: rpm-guide rpm-guide-intro-packaging-en.xml,1.1,1.2 Message-ID: <200510242034.j9OKYaLe032681@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv32657 Modified Files: rpm-guide-intro-packaging-en.xml Log Message: Tagging and trivial edits Index: rpm-guide-intro-packaging-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-intro-packaging-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- rpm-guide-intro-packaging-en.xml 4 Oct 2005 01:52:28 -0000 1.1 +++ rpm-guide-intro-packaging-en.xml 24 Oct 2005 20:34:34 -0000 1.2 @@ -1,30 +1,27 @@ - -Introducing Package Management - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - In This Chapter - - - - *Issues in software management - - - - *Examining Linux management tools - + + Introducing Package Management - *Introducing the package concept + This chapter covers: - + + + + Issues in software management + + + + + Examining Linux management tools + + + + + Introducing the package concept + + + In 1991, a young Finnish graduate student started a new personal hobby. He had acquired an Intel 386 computer and had spent a few @@ -35,16 +32,14 @@ exploring Minix, a feature-limited teaching operating system, he decided he needed a full-featured OS. - At that time, no full-featured PC operating systems were freely available, so he decided to write his own operating system. Today, that small hobby OS that Linus Torvalds started almost as a whim has - become Linux (www.linux.com), a significant new variant of Unix that - runs millions of the world's network servers and, increasingly, - desktop computers and embedded processors. + become Linux, a significant new variant of Unix that runs millions + of the world's network servers and, increasingly, desktop computers + and embedded processors. - Linux has grown up, successfully making the transition from a one-man personal project to a functional, full-featured operating @@ -57,7 +52,6 @@ other installed packages? And how can you safely upgrade packages? Answering these questions is what this book is all about. - Installing, Removing, and Upgrading Applications @@ -104,14 +98,14 @@ distributed as source code. To install a new application, such as the Apache Web server, you download the source code for that application???in this case, from the Apache Project's Web page - (http://httpd.apache.org). Typically, the source code is provided - in some sort of archive (such as the Zip archival and compression - format often used in the Windows world or the tar archive format - typically used in the Unix world) that you must then unpack. After - unpacking this source code, you have to configure it to support - the options and systems you want, compiling it to produce an - executable program that can run on your particular operating - system (CPU combination). + (). Typically, the source + code is provided in some sort of archive (such as the Zip archival + and compression format often used in the Windows world or the tar + archive format typically used in the Unix world) that you must + then unpack. After unpacking this source code, you have to + configure it to support the options and systems you want, + compiling it to produce an executable program that can run on your + particular operating system (CPU combination). After compiling the source code, you still have to install the @@ -171,19 +165,18 @@ is. - Overcoming the Installation Obstacles None of the tasks you must perform to install, upgrade, or uninstall applications are especially difficult. However, these steps quickly become daunting when you consider all the files that - must be managed. A full Red Hat Linux 7.3 installation provides - around 3,000 executable commands and over 160,000 total files - (some other Linux distributions are even larger!). Obviously, - managing all these files by hand, although theoretically possible, - is not technically feasible. On a smaller scale, even management - of single applications is not practical. The Postfix e-mail server + must be managed. A full &RHL; 7.3 installation provides around + 3,000 executable commands and over 160,000 total files (some other + Linux distributions are even larger!). Obviously, managing all + these files by hand, although theoretically possible, is not + technically feasible. On a smaller scale, even management of + single applications is not practical. The Postfix e-mail server application, for example, consists of around 275 files scattered in a dozen or so different directories. Imagine trying to remember and manually remove all of those files (and only those files) to @@ -219,13 +212,14 @@ perform the upgrade. Otherwise, the software must be manually upgraded using the procedure described previously. - - Note - - - Current versions of Windows, such as Windows XP, though, have a - central database of installed applications. - + + Current Windows Versions + + + Current versions of Windows, such as Windows XP, have a + central database of installed applications. + + Built-in system utilities @@ -297,12 +291,13 @@ and permissions. This single archive file can then be transferred to other machines, where a System V software-management command can be used to install it. This - System V installation command (typically called pkgadd) unpacks - the archive, copies the files into their final destinations - based on the enclosed listing, and sets permissions and - ownerships on the files as specified by the listing. Finally, - this pkgadd command registers the list of freshly installed - files into a system-wide database of installed files. + System V installation command (typically called + pkgadd) unpacks the archive, copies the files + into their final destinations based on the enclosed listing, and + sets permissions and ownerships on the files as specified by the + listing. Finally, this pkgadd command + registers the list of freshly installed files into a system-wide + database of installed files. Such a system offers several advantages over manual software @@ -317,7 +312,6 @@ - Linux Software Management Tools: Packages @@ -334,24 +328,26 @@ used by various distributions. - The Gentoo Linux (www.gentoo.org) distribution, for example, uses - a software-management system called Portage, which is very similar - to the FreeBSD ports system. Like ports, Portage provides great - control over software compilation and installation, providing a - collection of scripts that automate much of the basic work of - downloading and compiling software. + The Gentoo Linux () + distribution, for example, uses a software-management system + called Portage, which is very similar to the FreeBSD ports system. + Like ports, Portage provides great control over software + compilation and installation, providing a collection of scripts + that automate much of the basic work of downloading and compiling + software. At the other end of the spectrum, the now-defunct deepLinux - distribution used a software-management system called deep-package - (still available from - www2.cddc.vt.edu/linux/distributions/deeplinux/tools. deep-package - was intended to be a complete reimplementation of the Solaris - pkgadd utility and its helpers. Like the Solaris pkgadd software, - deep-package paid no attention to half of the question of how to - manage software, focusing entirely on software installation and - tracking issues while entirely ignoring the initial compilation of - the software. + distribution used a software-management system called + deep-package (still available from + ). + deep-package was intended to be a complete + reimplementation of the Solaris pkgadd utility + and its helpers. Like the Solaris pkgadd + software, deep-package paid no attention to + half of the question of how to manage software, focusing entirely + on software installation and tracking issues while entirely + ignoring the initial compilation of the software. More typically, however, Linux software-management tools use an @@ -383,7 +379,7 @@ software. - In the case of my full Red Hat Linux 7.3 installation, this + In the case of a full &RHL; 7.3 installation, this package-management software maintains a database of information regarding all 160,000 files on the system; as applications are installed on the system, this database is updated with information @@ -402,23 +398,24 @@ focuses on one of these tools, the RPM Package Management software, or RPM. + + Change of Name + + + RPM was originally called Red Hat Package Manager. After + adoption by other Linux distributions, the name has changed to + simply the RPM Package Manager. The RPM initials remain the + same. + + - Note - - - RPM was originally called Red Hat Package Manager. After adoption - by other Linux distributions, the name has changed to simply the - RPM Package Manager. The RPM initials remain the same. - - - As the original name implies, RPM was developed by Red Hat, Inc., + As the original name implies, RPM was developed by &FORMAL-RHI;, the major Linux distributor in the United States. Even though the - original name seems to point to a Red Hat-only solution, most - Linux distributions use the RPM software. The RPM software - provides a foundation needed by Linux system administrators - throughout the world. You can even use RPM on other operating - systems, both Linux and non-Linux, as covered in Chapters 19 and - 20, respectively. + original name seems to point to a &RH;-only solution, most Linux + distributions use the RPM software. The RPM software provides a + foundation needed by Linux system administrators throughout the + world. You can even use RPM on other operating systems, both Linux + and non-Linux, as covered in Chapters 19 and 20, respectively. The RPM system provides all of the features needed to manage @@ -432,50 +429,69 @@ with RPM packages and the commands you need to work with the RPM system: - - *Chapter 2 provides an overview of the RPM system, exploring what - it was designed for and where it has weaknesses. - - - *Chapter 3 discusses the technical details of how the RPM system - works, where the database of packages gets stored, and what - commands should be available for working with RPM packages. - - - *Chapter 4 continues the discussion by covering the three major - tasks you need to perform with RPM packages: installing software, - removing software, and upgrading software you have already - installed. - - - *Chapter 5 covers the RPM database, how it works, where it - resides, and how you can use it to better manage your system. - - - *Chapter 6 delves into package dependencies, a very important - concept. Most major applications depend on a number of other - packages. Sometimes these dependencies get very complex, with one - package depending on particular versions of other packages. With - thousands of packages on your system, this can lead to a big mess. - Chapter 6 helps you sort through the issues. - - - *Chapter 7 covers the important issue of transactions, so that you - can ensure your system gets updated in an orderly manner and so - that you can roll back changes if something does not work out. - - - *Chapter 8 introduces a host of tools that can help you find RPM - packages as well as manage the packages on your system. This - includes graphical interfaces on top of the RPM system and special - Internet search sites devoted just to RPM packages. - + + + + Chapter 2 provides an overview of the RPM system, exploring + what it was designed for and where it has weaknesses. + + + + + Chapter 3 discusses the technical details of how the RPM + system works, where the database of packages gets stored, and + what commands should be available for working with RPM + packages. + + + + + Chapter 4 continues the discussion by covering the three major + tasks you need to perform with RPM packages: installing + software, removing software, and upgrading software you have + already installed. + + + + + Chapter 5 covers the RPM database, how it works, where it + resides, and how you can use it to better manage your system. + + + + + Chapter 6 delves into package dependencies, a very important + concept. Most major applications depend on a number of other + packages. Sometimes these dependencies get very complex, with + one package depending on particular versions of other + packages. With thousands of packages on your system, this can + lead to a big mess. Chapter 6 helps you sort through the + issues. + + + + + Chapter 7 covers the important issue of transactions, so that + you can ensure your system gets updated in an orderly manner + and so that you can roll back changes if something does not + work out. + + + + + Chapter 8 introduces a host of tools that can help you find + RPM packages as well as manage the packages on your system. + This includes graphical interfaces on top of the RPM system + and special Internet search sites devoted just to RPM + packages. + + + Later chapters cover creating RPM packages, programming with RPM, and extending the functionality provided by the base RPM system. - Summary From fedora-docs-commits at redhat.com Tue Oct 25 00:33:00 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 24 Oct 2005 20:33:00 -0400 Subject: rpm-guide rpm-guide-intro-rpm-en.xml,1.1,1.2 Message-ID: <200510250033.j9P0X0ds007642@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv7619 Modified Files: rpm-guide-intro-rpm-en.xml Log Message: Tagging and minor style edits Index: rpm-guide-intro-rpm-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-intro-rpm-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- rpm-guide-intro-rpm-en.xml 4 Oct 2005 01:53:01 -0000 1.1 +++ rpm-guide-intro-rpm-en.xml 25 Oct 2005 00:32:57 -0000 1.2 @@ -1,62 +1,53 @@ - - -Introduction to RPM - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Chapter - - - - *Examining the history of package management - - - - *Introducing RPM features - + + + Introduction to RPM - *Getting acquainted with RPM terminology + This chapter covers: - + + + + Examining the history of package management + + + + + Introducing RPM features + + + + + Getting acquainted with RPM terminology + + + - Several package managers???software that tracks and manipulates the - applications installed on the system???are available for Linux. The - most widely used of these Linux package managers is the RPM Package - Manager (formerly the Red Hat Package Manager), or RPM for short, - the subject of this book + Several package managers are available for Linux to track and + manipulate the applications installed on the system. The most widely + used of these Linux package managers is the RPM Package Manager + (formerly the Red Hat Package Manager), or RPM for short, the + subject of this book - - Although RPM was initially developed for Red Hat Linux, a - combination of technical features and good timing has resulted in - RPM???s becoming the de facto standard for packaging software on - most Linux distributions. The fact that Red Hat released the source - code to the RPM software under an open-source license also helped - its adoption. + Although RPM was initially developed for &RHL;, a combination of + technical features and good timing has resulted in RPM???s becoming + the de facto standard for packaging software on most Linux + distributions. The fact that &RH; released the source code to the + RPM software under an open-source license also helped its adoption. - More recently, the RPM package file format has been adopted as the official standard for Linux as part of the Linux Standards Base, or - LSB. Described at www.linuxbase.org/, the Linux Standards Base is an - attempt to set a baseline that all Linux distributions should - follow. Some vendors have been pulled in kicking and screaming, but - the LSB for the most part has really helped the job of system - administrators by providing some commonality across distributions, - as in the location of certain files. The history of Linux package - managers is largely intertwined with the history of Linux - distributions. + LSB. Described at , the + Linux Standards Base is an attempt to set a baseline that all Linux + distributions should follow. Some vendors have been pulled in + kicking and screaming, but the LSB for the most part has really + helped the job of system administrators by providing some + commonality across distributions, as in the location of certain + files. The history of Linux package managers is largely intertwined + with the history of Linux distributions. - Strictly speaking, Linux refers to a single piece of software, the Unix-like kernel that Linus Torvalds and cohorts have scattered all @@ -69,7 +60,6 @@ such as watches and PDAs, to desktop and server systems, all the way up to mainframes and supercomputing clusters. - The Need for Linux Package Management Systems @@ -83,16 +73,18 @@ Despite this controversy, it is clear that most users of Linux require both the Linux kernel and a large suite of accompanying software (a shared C library; traditional Unix utilities such as - grep, awk, and sed; an editor, such as vi; a shell, such as the - Bourne-Again "bash" shell; and so forth) to complete the various - tasks for which they typically employ Linux. + grep, awk, and + sed; an editor, such as vi; + a shell, such as the Bourne-Again bash shell; + and so forth) to complete the various tasks for which they + typically employ Linux. Users expect Linux to include server software such as the Apache Web server, desktop software such as the OpenOffice.org office productivity suite, and a host of other packages. In fact, most Linux users don???t make the distinction between the kernel - (technically the only part that is ???Linux???) and all the extra + (technically the only part that is Linux) and all the extra packages (technically ???everything else???) that comes with a Linux distribution. Most users simply refer to the whole thing as ???Linux.??? @@ -175,25 +167,27 @@ related applications, but what was really needed was installation and uninstallation on an application-by-application basis. + In late 1993, Rik Faith, Doug Hoffman, and Kevin Martin began releasing the first public betas of the BOGUS Linux distribution. - BOGUS was notable for the package management system (pms) software - that was used with it for installation and uninstallation of all - software on an application-by-application basis. Shortly - thereafter, in the summer of 1994, the first public betas of Red - Hat Commercial Linux were released. Red Hat initially used Red Hat - Software Program Packages (RPP) as the basis of its Linux - distribution. Like pms, RPP was a system-management tool that + BOGUS was notable for the package management system + (pms) software that was used with it for + installation and uninstallation of all software on an + application-by-application basis. Shortly thereafter, in the + summer of 1994, the first public betas of Red Hat Commercial Linux + were released. &RH; initially used Red Hat Software Program + Packages (RPP) as the basis of its Linux distribution. Like + pms, RPP was a system-management tool that allowed for easy installation and uninstallation of applications. In late 1993, Ian Murdock founded the Debian Gnu/Linux - distribution. He began seriously developing its dpkg - application-management software by the summer of 1994. Like pms - and RPP, dpkg made it possible to manage each application on the - system. + distribution. He began seriously developing its + dpkg application-management software by the + summer of 1994. Like pms and RPP, + dpkg made it possible to manage each + application on the system. - RPM Design Goals @@ -215,42 +209,60 @@ Because of these concerns, after their initial releases of - RPP-based distributions, Red Hat looked closely at both their own - RPP software and other software such as BOGUS's pms software. - Developers at Red Hat, particularly Marc Ewing and Erik Troan, set - out to develop what they initially called the Red Hat Package - Manager (RPM). Based on experiences with earlier Linux packaging - software and knowledge about packaging tools used on other - platforms, Red Hat had several design goals in mind when they + RPP-based distributions, &RH; looked closely at both their own RPP + software and other software such as BOGUS's pms + software. Developers at &RH;, particularly Marc Ewing and Erik + Troan, set out to develop what they initially called the Red Hat + Package Manager (RPM). Based on experiences with earlier Linux + packaging software and knowledge about packaging tools used on + other platforms, &RH; had several design goals in mind when they developed RPM. These design points include the following features: + + + + Ease of use + + + + + Package-oriented focus + + + + + Upgradability of packages + + + + + Tracking of package interdependencies + + + + + Query capabilities + + + + + Verification + + + + + Support for multiple architectures + + + + + Use of pristine sources + + + - *Ease of use - - - *Package-oriented focus - - - *Upgradability of packages - - - *Tracking of package interdependencies - - - *Query capabilities - - - *Verification - - - *Support for multiple architectures - - - *Use of pristine sources - - - The following sections demonstrate how Red Hat incorporated each - of these design goals into RPM. + The following sections demonstrate how &RH; incorporated each of + these design goals into RPM. Ease of use @@ -259,38 +271,55 @@ to use. Manual software installation has been the primary method of putting software onto Unix boxes for over 30 years now and has worked very well for those three decades. To offer a - compelling reason to use the new software, Red Hat's RPM must be + compelling reason to use the new software, RPM must be significantly easier to use than other Linux package-management tools. For that reason, most tasks that can be handled using RPM were designed to be carried out via a single command. For example, software installation using RPM requires a single - command (rpm -U software_package), while manual software - installation using older manual methods typically requires at - least six steps to complete the same task: - - - 1.tar zxf software_package - - - 2.cd software_package - - - 3../configure - - - 4.make - - - 5.su - - - 6.make install - + command (rpm -U software_package), while + manual software installation using older manual methods + typically requires at least six steps to complete the same task: + + + + + tar zxf + software_package + + + + + cd + software_package + + + + + ./configure + + + + + make + + + + + su + + + + + make install + + + Similarly, removal of applications installed using RPM requires - a single command (rpm -e software_package); manual removal of an - installed application requires that each file associated with - that application be manually deleted. + a single command (rpm -e + software_package); manual + removal of an installed application requires that each file + associated with that application be manually deleted. @@ -330,11 +359,12 @@ Apache's configuration information, which specifies things such as which files on the system should be made available as Web pages and who should be able to access those Web pages, is - stored in a text file, typically /etc/httpd/conf/httpd.conf. - Suppose Apache has been installed using RPM and that you have - then customized httpd.conf to specify its configuration. If you - upgrade Apache using RPM, as part of the upgrade procedure, the - RPM application will take precautions to preserve the + stored in a text file, typically + /etc/httpd/conf/httpd.conf. Suppose Apache + has been installed using RPM and that you have then customized + httpd.conf to specify its configuration. If + you upgrade Apache using RPM, as part of the upgrade procedure, + the RPM application will take precautions to preserve the customizations you have made to the Apache configuration. In contrast, manual upgrades of applications often overwrite any existing configuration files, losing all site customizations the @@ -347,12 +377,12 @@ Software that manages the applications installed on the system on an application level (such as RPM) does have one potential drawback in comparison with system-wide software management - systems (such as PC operating systems like Microsoft's Windows - or IBM's OS/2, which allow the entire system to be upgraded but - do not generally allow individual components to be upgraded, - added, or removed). Software applications often have - interdependencies; some applications work only when other - applications are installed. + systems (such as PC operating systems like Microsoft Windows or + OS/2, which allow the entire system to be upgraded but do not + generally allow individual components to be upgraded, added, or + removed). Software applications often have interdependencies; + some applications work only when other applications are + installed. The Postfix and Sendmail mail transfer agent (MTA) applications @@ -379,35 +409,39 @@ components, ensuring that all can still interoperate. On Microsoft Windows 2000, IIS (the application used on Windows to serve Web pages) requires several other applications such as - EventLog (the Windows application that records system events, - much like the Linux syslogd and klogd software) to be present. - Since Windows is managed on a system level, not a package level, - this dependency is guaranteed to be satisfied. On Linux systems - using RPM, however, the situation is different. On Linux, for - example, the Postfix application requires the syslogd - application, which records system events. However, RPM provides - the flexibility to install some applications but not install - others or to uninstall others later. When you install Postfix, - you have no guarantee that syslogd is already installed. If - syslogd is not installed, Postfix will not work correctly. - - - To avoid problems, Red Hat developers realized that RPMs must - also track dependency information about what software they - require for correct functionality, and that the RPM install and + EventLog (the Windows application that + records system events, much like the Linux + syslogd and klogd + software) to be present. Since Windows is managed on a system + level, not a package level, this dependency is guaranteed to be + satisfied. On Linux systems using RPM, however, the situation is + different. On Linux, for example, the Postfix application + requires the syslogd application, which + records system events. However, RPM provides the flexibility to + install some applications but not install others or to uninstall + others later. When you install Postfix, you have no guarantee + that syslogd is already installed. If + syslogd is not installed, Postfix will not + work correctly. + + + To avoid problems, &RH; developers realized that RPMs must also + track dependency information about what software they require + for correct functionality, and that the RPM install and uninstall applications must use this dependency information. Because of dependencies, installing Postfix using RPM on a - system without syslogd installed generates a warning that - syslogd must also be installed. Similarly, attempting to - uninstall syslogd from a system that already has Postfix - installed generates a warning that installed applications - require the software that is being deleted. These warnings can - be overridden if necessary, but by default RPM enforces these - dependencies (refusing, for example, to let you uninstall - syslogd without also uninstalling applications that require it, - such as Postfix), preventing you from accidentally breaking - applications by inadvertently uninstalling other software that - they require to operate. + system without syslogd installed generates a + warning that syslogd must also be installed. + Similarly, attempting to uninstall syslogd + from a system that already has Postfix installed generates a + warning that installed applications require the software that is + being deleted. These warnings can be overridden if necessary, + but by default RPM enforces these dependencies (refusing, for + example, to let you uninstall syslogd without + also uninstalling applications that require it, such as + Postfix), preventing you from accidentally breaking applications + by inadvertently uninstalling other software that they require + to operate. @@ -429,21 +463,21 @@ RPM also maintains a variety of information about each installed file in this system database, such as what permissions each file - should have and what size each file should be. Red Hat - developers designed this database to be useful for software - verification. Over time, installed software will fail to work - for reasons as mundane as the system administrator setting - incorrect permissions on files or as exotic as nuclear decay of - one of the computer's atoms releasing an alpha particle that can - affect the computer's memory, corrupting that bit of memory and - causing errors. Although RPM cannot prevent all errors that - cause installed software to fail (obviously, there's not a - single thing any software can do to prevent nuclear decay), it - can be used to eliminate common errors. When an application - fails, you can use the RPM database to make sure that all files - associated with that application still have correct Unix file - permissions and that no files associated with that application - have become altered or corrupted. + should have and what size each file should be. &RH; developers + designed this database to be useful for software verification. + Over time, installed software will fail to work for reasons as + mundane as the system administrator setting incorrect + permissions on files or as exotic as nuclear decay of one of the + computer's atoms releasing an alpha particle that can affect the + computer's memory, corrupting that bit of memory and causing + errors. Although RPM cannot prevent all errors that cause + installed software to fail (obviously, there's not a single + thing any software can do to prevent nuclear decay), it can be + used to eliminate common errors. When an application fails, you + can use the RPM database to make sure that all files associated + with that application still have correct Unix file permissions + and that no files associated with that application have become + altered or corrupted. @@ -468,8 +502,8 @@ series of processors were among the first additional CPUs that Linux supported. These days, Linux supports dozens of CPU architectures.) This posed a problem for distribution developers - such as Red Hat and Debian and for application vendors who - desired to package their software for use on Linux. Because the + such as &RH; and Debian, and for application vendors who desired + to package their software for use on Linux. Because the available packaging methods could not produce packages for multiple architectures, packagers making software for multiple CPUs had to do extra work to prepare their packages. @@ -481,7 +515,7 @@ machine types they could install the packages. - Red Hat decided to overcome these limitations by incorporating + &RH; decided to overcome these limitations by incorporating architecture support into RPM, adding features so that the basic setup a packager performs to create a package could be leveraged to produce packages that would run on various CPUs, and so that @@ -492,19 +526,19 @@ Pristine sources - The BOGUS distribution's pms packaging system introduced the use - of pristine source code to prepare packages. With Red Hat's - early RPP package system and other similar early efforts, - software packagers would compile software manually, then run - commands to produce a package of that compiled software. Any - changes made to the application's original source code were not - recorded and would have to be recreated by the next person to - package that software. Furthermore, end users wanting to know - what changes had been made to the software they were running had - no method of accessing that information. + The BOGUS distribution's pms packaging system + introduced the use of pristine source code to prepare packages. + With Red Hat's early RPP package system and other similar early + efforts, software packagers would compile software manually, + then run commands to produce a package of that compiled + software. Any changes made to the application's original source + code were not recorded and would have to be recreated by the + next person to package that software. Furthermore, end users + wanting to know what changes had been made to the software they + were running had no method of accessing that information. - With RPM, Red Hat developed a package system that produced two + With RPM, &RH; developed a package system that produced two types of packages: binary and source. Binary packages are compiled software that can be installed and used. Source packages contain the source code for that software, along with a @@ -523,7 +557,6 @@ - RPM Terminology @@ -540,82 +573,102 @@ To help in installation and management, all package files are - labeled with highly identifiable names. Red Hat Linux package - files have four-part names, which typically look something like: - - - kernel-smp-2.4.18-3.athlon.rpm - - - kernel-smp-2.4.18-3.i586.rpm - - - kernel-smp-2.4.18-3.i686.rpm - - - kernel-source-2.4.18-3.i386.rpm - - - rootfiles-7.2-1.noarch.rpm + labeled with highly identifiable names. Package files have + four-part names, which typically look something like: + + + + kernel-smp-2.4.18-3.athlon.rpm + + + + + kernel-smp-2.4.18-3.i586.rpm + + + + + kernel-smp-2.4.18-3.i686.rpm + + + + + kernel-source-2.4.18-3.i386.rpm + + + + + rootfiles-7.2-1.noarch.rpm + + + Here, the four parts of each name are separated from each other by dashes or periods. The structure of the package file name is - name-version-release.architecture.rpm + name-version-release.architecture.rpm The name identifies what software is contained within the archive file. Typically, this is a name of an application or package that - the archive installs on the system. For example, kernel-smp can be - installed to provide a very important application, the SMP - (symmetric multiprocessing, meaning it supports systems with more - than one CPU in them) version of the Linux kernel, on the system. - Sometimes, rather than an application, the software is a - collection of other files needed on the system. The rootfiles - package, for example, is not an application but is a collection of - basic environmental configuration files for the root user's - account (such as /root/.bashrc, the root user's Bash configuration - file) that provides a usable, preconfigured working environment - for the root user on Red Hat Linux systems. - - - The second field in every Red Hat Linux package file's name is the - version field. This field identifies the version number of the - software that is contained in the package file. For example, - kernel-smp-2.4.18 indicates the RPM holds the 2.4.18 release of - the SMP version of the Linux kernel, and rootfiles-7.2 is the 7.2 - release of the rootfiles configuration files. - - - Every Red Hat Linux package file name also has a third component: - the release field. This field identifies which release of that - version of the software the package file contains. Package files - contain both software and instructions about how to install that - software. As packages of a particular version of software are - being prepared, mistakes are sometimes made in these instruction - files, or bugs are sometimes fixed within a software version; more - recent package files of that software version need to be prepared - that correct the problem. The ???1 in the rootfiles-7.2-1 package - shows this is the first release of the 7.2 version of the - rootfiles software. The packager of rootfiles version 7.2 got - everything right on the first try and had no need to prepare more - than one release. The ???3 in the kernel-smp-2.4.18-3 package, on - the other hand, is the third release of the 2.4.18 version of the - SMP-capable Linux kernel. This release incorporates new patches to - fix bugs present in older releases of the 2.4.18 version of the - Linux SMP kernel. The software packager increased the release - number so that end users could distinguish the more recent, - bug-fixed package file from the older, less bug-free package file. - - - The final field in Red Hat Linux package file names is the - architecture, which identifies the system types for which the - package file is appropriate. For example, the - kernel-smp-2.4.18-3.athlon package is intended for use on machines - with an AMD Athlon CPU, and kernel-smp-2.4.18-3.i586 is intended - for use on machines with an i586 (Pentium-class) CPU or better. An + the archive installs on the system. For example, + kernel-smp can be installed to provide a very + important application, the SMP (symmetric multiprocessing, meaning + it supports systems with more than one CPU in them) version of the + Linux kernel, on the system. Sometimes, rather than an + application, the software is a collection of other files needed on + the system. The rootfiles package, for + example, is not an application but is a collection of basic + environmental configuration files for the + root user's account + (such as /root/.bashrc, the + root user's Bash + configuration file) that provides a usable, preconfigured working + environment for the root + user. + + + The second field in every package file's name is the version + field. This field identifies the version number of the software + that is contained in the package file. For example, + kernel-smp-2.4.18 indicates the RPM holds the + 2.4.18 release of the SMP version of the Linux kernel, and + rootfiles-7.2 is the 7.2 release of the + rootfiles configuration files. + + + Every package file name also has a third component: the release + field. This field identifies which release of that version of the + software the package file contains. Package files contain both + software and instructions about how to install that software. As + packages of a particular version of software are being prepared, + mistakes are sometimes made in these instruction files, or bugs + are sometimes fixed within a software version; more recent package + files of that software version need to be prepared that correct + the problem. The ???1 in the rootfiles-7.2-1 + package shows this is the first release of the 7.2 version of the + rootfiles software. The packager of + rootfiles version 7.2 got everything right on + the first try and had no need to prepare more than one release. + The ???3 in the kernel-smp-2.4.18-3 package, + on the other hand, is the third release of the 2.4.18 version of + the SMP-capable Linux kernel. This release incorporates new + patches to fix bugs present in older releases of the 2.4.18 + version of the Linux SMP kernel. The software packager increased + the release number so that end users could distinguish the more + recent, bug-fixed package file from the older, less bug-free + package file. + + + The final field in package file names is the architecture, which + identifies the system types for which the package file is + appropriate. For example, the + kernel-smp-2.4.18-3.athlon package is + intended for use on machines with an AMD Athlon CPU, and + kernel-smp-2.4.18-3.i586 is intended for use + on machines with an i586 (Pentium-class) CPU or better. An architecture name of noarch indicates this is a special architecture such that the files in the package work on any architecture. Typically, this is because the files are all @@ -627,7 +680,7 @@ 4.1. - Table 2-1Supported Architectures + Table 2-1 Supported Architectures @@ -792,32 +845,32 @@ - - Tip - - - When choosing an appropriate architecture for your machine, be - aware that more recent architectures typically run software that - targets older architectures within the same family; the reverse, - however, is not true. For example, within the 32-bit - Intel-compatible architectures, a 686-class (Pentium II / III / - IV) machine runs files within i386, i486, i586, and i686 RPM - package files, but a 386-class (80386) machine runs files within - i386 RPM package files only. Similarly, for the Alpha - architecture, more recent Alpha EV68 CPUs can run programs from - RPM package files with alphaev67, alphaev6, alphaev56, alphaev5, - and alpha architectures, but an older Alpha EV56 machine can run - programs from RPM package files with alpha, alphaev5, or alphaev56 - architectures only. - + + Architecture Compatibility + + When choosing an appropriate architecture for your machine, be + aware that more recent architectures typically run software that + targets older architectures within the same family; the reverse, + however, is not true. For example, within the 32-bit + Intel-compatible architectures, a 686-class (Pentium II / III / + IV) machine runs files within i386, i486, i586, and i686 RPM + package files, but a 386-class (80386) machine runs files within + i386 RPM package files only. Similarly, for the Alpha + architecture, more recent Alpha EV68 CPUs can run programs from + RPM package files with alphaev67, alphaev6, alphaev56, alphaev5, + and alpha architectures, but an older Alpha EV56 machine can run + programs from RPM package files with alpha, alphaev5, or + alphaev56 architectures only. + + Notice that the four fields in RPM package file names are separated from each other by punctuation, either a dash (-) or a period (.). Periods and dashes, however, are also allowed within - fields. 7.2 is a valid version number, just as kernel-source is a - valid software name. Finally, keep in mind that all RPM package - files use an .rpm file-name extension to denote that they are - RPMs. + fields. 7.2 is a valid version number, just as + kernel-source is a valid software name. + Finally, keep in mind that all RPM package files use an .rpm + file-name extension to denote that they are RPMs. Once installed, package names are slightly different from package @@ -825,24 +878,28 @@ Internet, copied off of CDs, and otherwise easily transferred between machines, always have names that looks like name-version-release.architecture.rpm. Installed packages, - however, have names that look like name-version-release. Once - installed, packages are referred to without the architecture field - and the .rpm extension. Furthermore, installed packages consist of - lots of files, not a single RPM file. For example, the package - file kernel-smp-2.4.18-3.i686.rpm after installation is referred - to as kernel-smp-2.4.18-3. To simplify usage even further, - installed packages can be referred to by their name field only, so - this file would become simply kernel-smp. - - - Warning - - - Once installed, the name of the package does not have to be the - same as the name portion of the original package file. By - convention though, the package name matches the name, version, and - release part of the file name. + however, have names that look like + name-version-release. Once installed, + packages are referred to without the architecture field and the + .rpm extension. Furthermore, installed packages consist of lots of + files, not a single RPM file. For example, the package file + kernel-smp-2.4.18-3.i686.rpm after + installation is referred to as + kernel-smp-2.4.18-3. To simplify usage even + further, installed packages can be referred to by their name field + only, so this file would become simply + kernel-smp. + + Software Names May Differ from Package Names + + + Once installed, the name of the package does not have to be the + same as the name portion of the original package file. By + convention though, the package name matches the name, version, + and release part of the file name. + + Usage of the name field by itself to name packages assumes that multiple versions or releases of that particular software are not @@ -852,42 +909,47 @@ uses an SMP-capable Linux kernel. On it, I have the following Linux SMP kernels installed: - - $ rpm -q kernel-smp - - - kernel-smp-2.4.18-4 - - - kernel-smp-2.4.18-3 - - - kernel-smp-2.5.21-4 - - - $ - - - This example uses the rpm ???q command to query for all installed - versions of the given package, kernel-smp. - - - Cross Reference - - - Chapter 5 covers querying the RPM database in depth. + + + + kernel-smp-2.4.18-4 + + + + + kernel-smp-2.4.18-3 + + + + + kernel-smp-2.5.21-4 + + + + + This example uses the rpm + command to query for all installed versions of the given package, + kernel-smp. + + The RPM Database + + + covers querying the RPM + database in depth. + + I have two different package file releases (release 3 and release 4) of the 2.4.18 version of the Linux kernel, and I have a development kernel, version 2.5.21, installed. On this system, - since I have multiple packages installed of the kernel-smp - software, I have to use the full package name (such as - kernel-smp-2.4.18-4) whenever I want to work with my installed - kernel-smp packages. + since I have multiple packages installed of the + kernel-smp software, I have to use the full + package name (such as kernel-smp-2.4.18-4) + whenever I want to work with my installed + kernel-smp packages. - Summary @@ -909,7 +971,7 @@ include nearly so many applications. From the OpenOffice.org office suite to the Apache Web server, Linux distributions are literally packed with applications. As a final point, most other - operating systems provide mostly closed-source applications. + operating systems provide mainly closed-source applications. Linux, on the other hand, includes thousands of open-source applications. @@ -919,22 +981,43 @@ for end users, the solution to these problems helps make the RPM system better able to manage user systems: - - *The RPM system tags each package with the processor architecture - and allows for multiple versions of the same package to be - installed on the same system. RPM also packs all the files in a - package into one file, called an RPM file, for easy transfer to - other systems. - - - *Most RPM operations such as installing or removing packages - require only a single command to run. - - - *The RPM system supports building RPM packages from a pristine set - of sources. This means you can reproduce the commands required to - build an application, improving quality. - + + + + Supports Multiple Architectures — The RPM system tags + each package with the processor architecture. + + + + + Permits Multiple Software Versions in Parallel — RPM + allows for multiple versions of the same package to be + installed on the same system. + + + + + One File Per Program — RPM packs all of the files in a + package into one file, called an RPM file, for easy transfer + to other systems. + + + + + Requires Only One Command Per Action — Most RPM + operations such as installing or removing packages require + only a single command to run. + + + + + Uses Pristine Sourcecode — The RPM system supports + building RPM packages from a pristine set of sources. This + means you can reproduce the commands required to build an + application, improving quality. + + + This chapter introduced the RPM system and the history behind it. The next chapter delves into the RPM basics, including files, From fedora-docs-commits at redhat.com Tue Oct 25 02:48:52 2005 From: fedora-docs-commits at redhat.com (Karsten Wade (kwade)) Date: Mon, 24 Oct 2005 22:48:52 -0400 Subject: release-notes daemons-en.xml, NONE, 1.1 database-servers-en.xml, NONE, 1.1 desktop-en.xml, NONE, 1.1 development-tools-en.xml, NONE, 1.1 feedback-en.xml, NONE, 1.1 file-servers-en.xml, NONE, 1.1 file-systems-en.xml, NONE, 1.1 hardware-reqs-en.xml, NONE, 1.1 install-notes-en.xml, NONE, 1.1 intro-en.xml, NONE, 1.1 java-package-en.xml, NONE, 1.1 kernel-en.xml, NONE, 1.1 misc-server-en.xml, NONE, 1.1 multimedia-en.xml, NONE, 1.1 networking-en.xml, NONE, 1.1 overview-en.xml, NONE, 1.1 package-movement-en.xml, NONE, 1.1 package-notes-en.xml, NONE, 1.1 printing-en.xml, NONE, 1.1 project-overview-en.xml, NONE, 1.1 samba-en.xml, NONE, 1.1 security-en.xml, NONE, 1.1 server-tools-en.xml, NONE, 1.1 splash-en.xml, NONE, 1.1 web-servers-en.xml, NONE, 1.1 xorg-en.xml, NONE, 1.1 fedora.css, 1.1, 1.2 daemons.xml, 1.1, NONE database-servers.xml, 1.1, NONE desktop.xml, 1.1, NONE development-tools.xml, 1.1, NONE feedback.xml, 1.1, NONE file-servers.xml, 1.1, NONE file-systems.xml, 1.1, NONE hardware-reqs.xml, 1.1, NONE install-notes.xml, 1.1, NONE intro.xm! l, 1.1, NONE java-package.xml, 1.1, NONE kernel.xml, 1.1, NONE misc-server.xml, 1.1, NONE multimedia.xml, 1.1, NONE networking.xml, 1.1, NONE overview.xml, 1.1, NONE package-movement.xml, 1.1, NONE package-notes.xml, 1.1, NONE printing.xml, 1.1, NONE project-overview.xml, 1.1, NONE samba.xml, 1.1, NONE security.xml, 1.1, NONE server-tools.xml, 1.1, NONE splash.xml, 1.1, NONE web-servers.xml, 1.1, NONE xorg.xml, 1.1, NONE Message-ID: <200510250248.j9P2mqTG011469@cvs-int.fedora.redhat.com> Author: kwade Update of /cvs/docs/release-notes In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv11423 Modified Files: fedora.css Added Files: daemons-en.xml database-servers-en.xml desktop-en.xml development-tools-en.xml feedback-en.xml file-servers-en.xml file-systems-en.xml hardware-reqs-en.xml install-notes-en.xml intro-en.xml java-package-en.xml kernel-en.xml misc-server-en.xml multimedia-en.xml networking-en.xml overview-en.xml package-movement-en.xml package-notes-en.xml printing-en.xml project-overview-en.xml samba-en.xml security-en.xml server-tools-en.xml splash-en.xml web-servers-en.xml xorg-en.xml Removed Files: daemons.xml database-servers.xml desktop.xml development-tools.xml feedback.xml file-servers.xml file-systems.xml hardware-reqs.xml install-notes.xml intro.xml java-package.xml kernel.xml misc-server.xml multimedia.xml networking.xml overview.xml package-movement.xml package-notes.xml printing.xml project-overview.xml samba.xml security.xml server-tools.xml splash.xml web-servers.xml xorg.xml Log Message: Renaming files to have English suffix, now these can be translated properly. --- NEW FILE daemons-en.xml ---
System Services
<filename>cron</filename> and <filename>slocate</filename> The updatedb utility is no longer automatically run by cron to create and update the database of files used by slocate. Updating this database is an intensive process that users of workstations and laptops may find disruptive. To enable daily updates of the slocate database, edit the file /etc/updatedb.conf as follows: DAILY_UPDATE=yes --- NEW FILE database-servers-en.xml --- --- NEW FILE desktop-en.xml --- --- NEW FILE development-tools-en.xml ---
Development Tools
GCC Compiler Collection &DISTRO; &DISTROVER; has been built using GCC 4.0, which is included with the distribution. Caveats GDB 6.1 or newer is needed to debug binaries unless compiled using the -fno-var-tracking compilation option. The -fwritable-strings option is no longer accepted. English-language diagnostic messages now use Unicode quotes; if you cannot read this, set your LC_CTYPE environment variable to "C" or change your terminal emulator. The specs file is no longer installed on most systems. Ordinary users will not notice, but developers who need to alter the file can use the -dumpspecs option to generate the file for editing. Code Generation The SSA code optimizer is now included and brings with it better constant propagation, partial redundancy elimination, load and store code motion, strength reduction, dead storage elimination, better detection of unreachable code, and tail recursion by accumulation. Autovectorization is supported. This technique achieves higher performance for repetitive loop code, in some circumstances. Language Extentions A sentinel attribute has been added so that the compiler will now issue a warning if a function such as execl(char *path, const char *arg, ...), which requires a NULL list terminator is missing the NULL. The cast-as-lvalue, conditional-expression-as-lvalue, and compund-expression-as-lvalue extentions have been removed. The #pragma pack() semantics have been brought closer to those used by other compilers. Taking the address of a variable declared with the register modifier now generates an error instead of a warning. Arrays of incomplete element types now generate an error. This implies no forward reference to structure definitions. The basic compiler, without any optimization (-O0), has been measured as much as 25% faster in real-world code. Libraries may now contain function-scope static variables in multi-threaded programs. The -fno-threadsafe-statics can be used by embedded developers to turn off this feature, but ordinary users should never do this. Java To avoid naming conflicts: rmic is now grmic; rmiregistry is now grmiregistry; and jar is now fastjar. The GCJ compiler can now be used as a just-in-time (JIT) tool by using the gnu.jit facilities. More support of the AWT and SWING packages have been added. FORTRAN The GNU FORTRAN 77 front end has been replaced by a new FORTRAN 90/95 recognizer. Eclipse Development Environment Eclipse 3.1M6 has been compiled as a native application. The C Development Tool (CDT) has been included.
--- NEW FILE feedback-en.xml ---
Release Notes Feedback Procedure (This section will disappear when the final &DISTRO; release is created.) If you feel that these release notes could be improved in some way, you can provide feedback directly to the author. If you see a URL in the release notes that looks like this: %%% https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=<bug-number> %%% You can click on the URL and submit feedback on that particular section of the release notes. Your feedback will be added as a comment to an existing bug report. If the section of the release notes that you have feedback for does not have one of these URLs (or you are submitting a request for entirely new content), you can click on the following link (this only works for the HTML version, of course — the URL is much too long to include in the text): Click here to submit new release notes feedback If you would like to review the changes that have been already submitted for this document, use the following link: http://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=114398 As bugs are posted for the various parts of the release notes, subsequent test versions of these release notes will contain links similar to the one described earlier. Thank you (in advance) for your feedback!
--- NEW FILE file-servers-en.xml ---
File Servers This section refers to file transfer and sharing servers. Please refer to the &WEB-SERVERS; and &SAMBA; sections for information on HTTP (Web) file transfer and Samba (Windows) file sharing.
Netatalk (Macintosh Compatibility) This section contains information related to Netatalk, a suite of software that enables Linux to interact with Macintosh systems using the AppleTalk network protocols.
<filename>netatalk</filename> &DISTRO; &DISTROVER; includes version 2 of Netatalk. Upgrading from Netatalk version 1 to version 2 may result in data loss. Version 2 of Netatalk uses a different method to store file resource forks from the previous version, and may require a different file name encoding scheme. Please read the documentation and plan your migration before upgrading. Upgrade information is available directly from the Netatalk site: http://netatalk.sourceforge.net/2.0/htmldocs/upgrade.html The documentation is also included in the netatalk package. Refer to either /usr/share/doc/netatalk-2.0.2/doc/htmldocs/upgrade.html, or /usr/share/doc/netatalk-2.0.2/doc/Netatalk-Manual.pdf (numbered page 25, document page 33).
--- NEW FILE file-systems-en.xml --- --- NEW FILE hardware-reqs-en.xml ---
Hardware Requirements The following information represents the minimum hardware requirements necessary to successfully install &DISTRO; &DISTROVER;. Note The compatibility/availability of other hardware components (such as video and network cards) may be required for specific installation modes and/or post-installation usage.
CPU Requirements This section lists the CPU specifications required by &DISTRO; &DISTROVER;. <!-- <remark os="test">(x86)</remark>--> Note The following CPU specifications are stated in terms of Intel processors. Other processors (notably, offerings from AMD, Cyrix, and VIA) that are compatible with and equivalent to the following Intel processors may also be used with &DISTRO;. Minimum: Pentium-class — &FC; &LOCALVER; is optimized for Pentium 4 CPUs, but also supports earlier CPUs (such as Pentium, Pentium Pro, Pentium II, Pentium III, and including AMD and VIA variants). This approach has been taken because Pentium-class optimizations actually result in reduced performance for non-Pentium-class processors, and Pentium 4 scheduling is sufficiently different (while making up the bulk of today's processors) to warrant this change. Recommended for text-mode: 200 MHz Pentium-class or better Recommended for graphical: 400 MHz Pentium II or better AMD64 processors (both Athlon64 and Opteron) Intel processors with Intel Extended Memory 64 Technology (Intel EM64T)
Hard Disk Space Requirements This section lists the disk space required to install &DISTRO; &DISTROVER;. Note The disk space requirements listed below represent the disk space taken up by &DISTRO; &DISTROVER; after the installation is complete. However, additional disk space is required during the installation to support the installation environment. This additional disk space corresponds to the size of /Fedora/base/stage2.img (on CD-ROM 1) plus the size of the files in /var/lib/rpm on the installed system. In practical terms, this means that as little as an additional 90MB can be required for a minimal installation, while as much as an additional 175MB can be required for an "everything" installation. Also, keep in mind that additional space will be required for any user data, and at least 5% free space should be maintained for proper system operation. This list is for 32-bit x86 systems: Custom Installation (Minimal): 620MB Server: 1.1GB Personal Desktop: 2.3GB Workstation: 3.0GB Custom Installation (Everything): 6.9GB This list is for 64-bit x86_64 systems: Custom Installation (Minimal): 900MB Server: 1.5GB Personal Desktop: 2.7GB Workstation: 3.4GB Custom Installation: (Everything) 7.5GB
Memory Requirements This section lists the memory required to install &DISTRO; &DISTROVER;. This list is for 32-bit x86 systems: Minimum for text-mode: 64MB Minimum for graphical: 192MB Recommended for graphical: 256MB This list is for 64-bit x86_64 systems: Minimum for text-mode: 128MB Minimum for graphical: 256MB Recommended for graphical: 512MB
PPC Hardware Requirements This section lists the minimum PowerPC (PPC) hardware needed to install &FC; &LOCALVER;. Minimum: PowerPC G3 / POWER4 &FC; &LOCALVER; supports only the New World generation of Apple Power Macintosh, shipped circa 1999 onwards. It also supports the 64-bit G5 processor and, POWER processors in IBM eServer pSeries. Currently 32-bit IBM RS/6000 machines are not supported. Recommended for text-mode: 233 MHz G3 or better Recommended for graphical: 400 MHz G3 or better
--- NEW FILE install-notes-en.xml ---
Installation-Related Notes This section outlines those issues that are related to Anaconda (the &DISTRO; installation program) and installing &DISTRO; &DISTROVER; in general. Note If you intend to download the &DISTRO; &DISTROVER; DVD ISO image, keep in mind that not all file downloading tools can accommodate files larger than 2GB in size. For example, wget will exit with a File size limit exceeded error. The curl and ncftpget file downloading tools do not have this limitation, and can successfully download files larger than 2GB. Bittorrent is another method for downloading large files. For information about obtaining and using the torrent file refer to this website: http://torrent.fedoraproject.org/
PPC Installation Notes The DVD or first CD of the installation set of &FC; is set to be bootable on the Apple Macintosh and should boot the appropriate 32-bit or 64-bit installer. In addition, bootable CD images can be found in the images/ directory of the DVD or first CD. Choose the appropriate boot.iso according to the hardware: images/mac/boot.iso - 32-bit Apple Macintosh (G3/G4) images/mac64/boot.iso - 64-bit Apple Macintosh (G5) images/pseries/boot.iso - 64-bit IBM eServer pSeries (POWER4/POWER5) Power management support, including sleep and backlight level management, is present in the apmud package, which is in &FEX;. &FEX; for &FC; is configured by default for yum. Following installation, apmud can be installed by running yum install apmud.
Anaconda Notes The &DISTRO; installation program has the ability to test the integrity of the installation media. It works with the CD, DVD, hard drive ISO, and NFS ISO installation methods. &RH; recommends that you test all installation media before starting the installation process, and before reporting any installation-related bugs (many of the bugs reported are actually due to improperly-burned CDs). To use this test, type linux mediacheck at the boot: prompt. The mediacheck function is highly sensitive, and may report some usable discs as faulty. This result is often caused by disc writing software that does not include padding when creating discs from ISO files. For best results with the mediacheck, boot with the option: linux ide=nodma Use the sha1sum utility to verify discs before carrying out an installation. This test accurately identifies discs that are not valid or identical to the ISO image files. Memory testing may be performed prior to installing &DISTRO; by entering memtest86 at the boot: prompt. This causes the Memtest86 standalone memory testing software to run. Memtest86 memory testing continues until the Esc key is pressed. NOTE: You must boot from CD-ROM 1 (or a rescue CD-ROM) in order to use this feature. &DISTRO; &DISTROVER; supports graphical FTP and HTTP installations. However, due to the necessity of containing the installer image in RAM, only systems with more than 128MB of RAM (or systems booted from CD-ROM 1, which contains the installer image) can use the graphical installer. Systems with 128MB or less will continue to use the text-based installer.
Installation-Related Issues Certain hardware configurations (particularly those with LCD displays) may experience problems while starting the &DISTRO; installation program. In these instances, restart the installation, and add the "nofb" option to the boot command line. Note Chinese, Japanese, and Korean graphical installations started using the "nofb" option will start in English, and then switch to the appropriate language once the graphical phase of the installation process begins. Some Sony VAIO notebook systems may experience problems installing &DISTRO; from CD-ROM. If this happens, restart the installation process and add the following option to the boot command line: pci=off ide1=0x180,0x386 This option allows the installation to proceed normally; any devices not detected due to the use of this option will be configured the first time &DISTRO; is booted. Serial mice are known to be inoperative during installation. However, there are indications that serial mice work properly in X after the installation has completed. Refer to bug 119474 for more information: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119474 There have been issues observed when upgrading &RHL; 7.<x>, 8.0, 9, and &FC; 1, 2, and 3 systems where third party packages are installed that conflict with packages provided by &FP;. One example is Ximian GNOME. The issue with Ximian GNOME is caused by version overlap between the official &RHL; RPMs (or the ones from the &PROJ;) and the Ximian RPMs. This configuration is not supported. You have several choices in resolving this particular issue: You may remove Ximian GNOME from your system prior to upgrading to &DISTRO;. You may upgrade your system, and then immediately reinstall Ximian GNOME. You may upgrade your system, and then immediately remove all remaining Ximian RPMs, replacing them with the corresponding &DISTRO; RPMs. You must resolve the version overlap using one of the above choices. Failure to do so will result in an unstable GNOME configuration.
--- NEW FILE intro-en.xml ---
Introduction and Technical Release Notes The &PROJ; is an openly-developed project designed by &RH;, open for general participation, led by a meritocracy, and following a set of project objectives. The results from this project include &DISTRO;, which is a complete, general-purpose operating system built exclusively from open source software. Note &FC; is a community supported project. &FC; is not a commercially supported product of &FORMAL-RHI;. For more information, refer to . Additional important information about this release may be made available at http://fedora.redhat.com/docs/release-notes/. Users are advised to check this link regularly for updates. For reporting errors or other requests about these release notes, file a bug report using this pre-filled bugzilla template. This &TINY-BUG-URL; will take you to the same pre-filled bugzilla template.
--- NEW FILE java-package-en.xml ---
Java Package Recommendations &FC; &LOCALVER; users are advised not to use the Java RPM provided by Sun. It contains Provides that conflict with names used in packages provided as part of &FC; &LOCALVER;. Because of this, Sun Java might disappear from an installed system during package upgrade operations. &FC; &LOCALVER; users should use either the RPM from jpackage.org or manually install the Sun Java tarball into /opt. Sun Java 1.5+ is recommended for stability purposes.
--- NEW FILE kernel-en.xml ---
Linux Kernel
Version The &DISTRO; is based on a 2.6.11 kernel. &FC; may include additional patches for improvements, bug fixes, or additional features. For this reason, the &FC; kernel may not be line-for-line equivalent to the so-called vanilla kernel from the kernel.org web site. You may obtain a list of any such patches by using the command on the &FC; package: rpm -qpl kernel-<version>.src.rpm
Kernel Flavors &FC; includes the following kernel builds: Native kernel, in both uniprocessor and SMP varieties. Configured sources are available in the kernel-devel-<version>.<arch>.rpm package. Virtual kernel for use with the Xen emulator package. Configured sources are available in the kernel-xen0-devel-<version>.<arch>.rpm package. Sources for both kernel flavors may be installed at the same time. The files will be installed into the /usr/src/kernels/<version>[-xen0]-<arch>/ tree. Use the command: rpm -Uvh kernel-devel[-xen0]-<version>.<arch>.rpm as appropriate. Following Generic Textbooks Many of the tutorials, examples, and textbooks about Linux kernel development assume the kernel sources are installed under the /usr/src/linux directory. If you make a symbolic link, as shown below, you should be able to use those learning materials with the &FC; packages. Install the appropriate kernel sources, as shown earlier, and then: ln -s /usr/src/kernels/kernel-<all-the-rest> /usr/src/linux
Preparing for Kernel Development &DISTRO; &DISTROVER; does not include the kernel-source package provided by older versions. Instead, configured sources are available as described in . Users that require access to &FC; original kernel sources can find them in the kernel .src.rpm package. To create an exploded source tree from this file, perform the following steps: These Instructions Refer to the Currently-running Kernel! To simplify the following directions, we have assumed that you want to configure the kernel sources to match your currently-running kernel. In the steps below, you must understand that the phrase <version> refers to the kernel version shown by this command: uname -r Obtain the kernel-<version>.src.rpm file from one of the following sources: The SRPMS directory on the appropriate SRPMS CD iso image. The FTP site where you got the kernel package. By running the following command: up2date --get-source kernel Install kernel-<version>.src.rpm using the command: rpm -Uvh kernel-<version>.src.rpm This writes the RPM contents into /usr/src/redhat/SOURCES and /usr/src/redhat/SPECS. Prepare the kernel sources using the commands: cd /usr/src/redhat/SPECS rpmbuild -bp --target $(arch) kernel-2.6.spec The kernel source tree will be located in the /usr/src/redhat/BUILD/kernel-<version> directory. It is common practice to move the resulting linux-<version> directory to the /usr/src tree; while not strictly necessary, we suggest that you do this to match the generally-available documentation. cd /usr/src/redhat/BUILD/kernel-<version> /usr/src/ mv linux-<version> /usr/src/ cd /usr/src ln -s ./linux-<version> linux cd /usr/src/linux The configurations for the specific kernels shipped in &DISTRO; &DISTROVER; are in the configs/ directory. For example, the i686 SMP configuration file is named configs/kernel-<version>-i686-smp.config. Issue the following command to place the desired configuration file in the proper place for building: cp configs/<desired-config-file> .config You can also find the .config file that matches your current kernel configuration in the /lib/modules/<version>/build/.config file. Every kernel gets a name based on its version number. This is the value the uname -r command displays. The kernel name is defined by the first four lines of the kernel Makefile. To protect the innocent, the Makefile has been changed to generate a kernel with a different name from that of the running kernel. Before a module can be accepted by the running kernel, that module must have been compiled for a kernel with the correct name. To do this, you must edit the kernel Makefile For example, if the uname -r returns the string 2.6.11-1.234_FC4, change the EXTRAVERSION definition from this: EXTRAVERSION = -prep to this: EXTRAVERSION = -1.234_FC4 that is, substitute everything from the final dash onward. Issue the following command: make oldconfig You can then proceed as usual.
Building Only Kernel Modules An exploded source tree is not required to build a kernel module, such as your own device driver, against the currently in-use kernel. For example, to build the foo.ko module, create the following Makefile in the directory containing the foo.c file: obj-m := foo.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) default: $(MAKE) -C $(KDIR) M=$(PWD) modules Issue the make command to build the foo.ko module.
User Space Dependencies on the Kernel &DISTRO; adds support for clustered systems. This requires a special kernel that works in conjunction with some user-space utilities, such as management daemons. Consequently, to remove such a kernel, perhaps after an update, you cannot simply use the rpm -e kernel-<version> command as in earlier distributions because these user space packages depend on the kernel package. You may either list both the kernel package and its user space dependent packages on the rpm -e command, or you may wish to use the yum remove kernel-<version> command instead since yum automatically removes dependent packages if necessary.
--- NEW FILE misc-server-en.xml ---
Miscellaneous Notes This section contains information related to packages that do not fit in any of the preceeding categories.
OpenOffice and upgrading from test releases If you choose to go counter to the recommendation to not upgrade from a previous test release, you may encounter a problem with OpenOffice following the upgrade. To resolve this, you must do the following command before doing the upgrade: rm -rf /usr/lib/openoffice.org*/share/template/*/wizard/bitmap
--- NEW FILE multimedia-en.xml ---
Multimedia This section contains information related to multimedia applications.
--- NEW FILE networking-en.xml ---
Networking This section contains information relating to network connectivity.
<filename>NetworkManager</filename> The NetworkManager service allows computers such as laptops to automatically manage changing network connections. It includes support for wireless networking. You must manually enable the NetworkManager service. To do so, type the following in a terminal window: su -c '/sbin/chkconfig --level 345 NetworkManager on; /sbin/service NetworkManager start' su -c '/sbin/chkconfig --level 345 NetworkManagerDispatcher on; /sbin/service NetworkManagerDispatcher start' Enter the root password when prompted. Use the Network Monitor desktop applet to monitor and configure NetworkManager. To load the applet in GNOME, right-click on the panel and select: Add to Panel...Network Monitor NetworkManager uses BIND to proxy DNS requests. Enabling the NetworkManager service also loads the named service as well. By default BIND is configured as a cacheing service for the local system, and does not accept connections from other systems. Note that some wireless network cards require drivers or firmware that cannot be included with &DISTRO;. This software must be installed separately for NetworkManager to function. --- NEW FILE overview-en.xml ---
Overview of This Release The following list includes brief summaries of some of the more significant aspects of &DISTRO; &DISTROVER;: &DISTRO; &DISTROVER; contains the following changes: Support for the PowerPC (PPC) architecture. GCC 4.0 GNOME 2.10 KDE 3.4 — includes new accessibility features. You can manage these new features in KDS Control CenterRegional & AccessibilityAccessibility. Native Eclipse 3.1M6 (part of a free Java stack) MySQL 4.1 PHP 5.0 Xen 2 (virtualization to run multiple versions of an OS) GFS 6.1-0.pre22 (cluster file system) Evince 0.2.1 (universal document viewer) GDM 2.6 - Includes early login capability &SEL; — This release includes coverage for 80 new daemons by the targeted policy. There are changes to the handling of Booleans. The targeted policy is enabled by default. For more information, refer to: http://fedora.redhat.com/docs/selinux-faq/. This is the complete list of daemons covered by the targeted policy: NetworkManager amanda apache apmd arpwatch auditd bluetooth canna cardmgr checkpolicy chkpwd compat comsat consoletype cpucontrol cpuspeed crond cups cvs cyrus dbskkd dbusd dhcpc dhcpd dictd dmidecode dovecot fingerd fsadm ftpd getty hald hostname hotplug howl hwclock i18n_input ifconfig inetd init initrc innd kerberos klogd ktalkd kudzu ldconfig load_policy login lpd mailman modutil mta mysqld named netutils nscd ntpd portmap postgresql ppd privoxy radius radvd restorecon rlogind rpcd rpm rshd rsync samba saslauthd sendmail setfiles slapd snmpd squid ssh stunnel syslogd telnetd tftpd udev updfstab uucpd webalizer winbind xdm ypbind ypserv zebra
--- NEW FILE package-movement-en.xml ---
Packages Movement
Packages Moved to &FEX; These are some of the packages that have moved from &CORE; to &FEX;. These are active packages that are maintained and supported by the &FP;. If you are looking for information about &EX;, refer to this URL: http://fedoraproject.org/wiki/Extras List is Incomplete This list highlights some of the major packages that moved from &CORE; to &EX; between &FC; 3 and &FC; &LOCALVER;. This is not a complete list. abiword aiksaurus balsa bzflag cyrus-imapd dbh dietlibc exim freeciv gnuchess gnumeric grip jed lapack libgda libgnomedb libtabe libxfce4mcs libxfce4util libxfcegui Maelstrom ncftp ots recode SDL_image SDL_mixer SDL_net sylpheed system-switch-im xboard xcin xemacs xemacs-sumo xfce4-iconbox [...2192 lines suppressed...] (x86;x86_64) raidtools (x86;x86_64) redhat-java-rpm-scripts (x86;x86_64) rep-gtk (x86_64) samba (i386) (x86;x86_64) sawfish (x86;x86_64) servletapi (x86;x86_64) servletapi-devel (x86;x86_64) shapecfg (x86;x86_64) struts (x86;x86_64) struts-webapps (x86;x86_64) system-config-proc (x86;x86_64) tomcat (x86;x86_64) tomcat-devel (x86;x86_64) tomcat-libs (x86;x86_64) tomcat-test (x86;x86_64) unarj (x86;x86_64) xalan-j (x86;x86_64) xalan-j-devel (x86;x86_64) xalan-j-xsltc (x86;x86_64) xerces-j (x86;x86_64) xerces-j-devel (x86;x86_64) xffm-icons (x86;x86_64) xorg-x11-100dpi-fonts (x86;x86_64) xorg-x11-75dpi-fonts (x86;x86_64) xorg-x11-ISO8859-14-100dpi-fonts (x86;x86_64) xorg-x11-ISO8859-14-75dpi-fonts (x86;x86_64) xorg-x11-ISO8859-15-100dpi-fonts (x86;x86_64) xorg-x11-ISO8859-15-75dpi-fonts (x86;x86_64) xorg-x11-ISO8859-2-100dpi-fonts (x86;x86_64) xorg-x11-ISO8859-2-75dpi-fonts (x86;x86_64) xorg-x11-ISO8859-9-100dpi-fonts (x86;x86_64) xorg-x11-ISO8859-9-75dpi-fonts (x86;x86_64) xorg-x11-base-fonts (x86;x86_64) xorg-x11-cyrillic-fonts (x86;x86_64) xorg-x11-libs-data (x86;x86_64) xorg-x11-syriac-fonts (x86;x86_64) xorg-x11-truetype-fonts
Packages Deprecated The following packages have been deprecated, and may be removed from a future release of &DISTRO;: dbskkd-cdb — Only used by deprecated package skkinput FreeWnn — Only used by deprecated package kinput2-canna-wnn6 (x86) lilo — GRUB is the recommended bootloader miniChinput — IIIMF is the recommended input method nabi — IIIMF is the recommended input method ncpfs — No longer part of &DISTRO; profile skkinput — IIIMF is the recommended input method xcin — IIIMF is the recommended input method
-->
--- NEW FILE package-notes-en.xml ---
Package-Specific Notes The following sections contain information regarding packages that have undergone significant changes for &DISTRO; &DISTROVER;. For easier access, they are generally organized using the same groups used in Anaconda.
Basic Components This section contains information related to basic system components.
&FEX; Repository &FEX; is part of the larger &FP; and is a volunteer-based community effort to create a repository of packages that compliment &FC;. The &FEX; repository is enabled by default from &FC; &LOCALVER; onwards. You can lean more about &FEX; from: http://fedoraproject.org/wiki/Extras If you would like to install any software available from Fedora extras you can use yum. yum install <packagename> Where <packagename> is the name of the package you want to install. For example, if you wanted to install the abiword package, the command yum install abiword automatically installs the package and all dependencies.
Audit Daemon <command>auditd</command> and Log Files The audit daemon, auditd, is now enabled by default. When auditd is running, the kernel directs audit messages to /var/log/audit/audit.log. The location of this file is specified in /etc/auditd.conf. AVC messages for &SEL; are sent using the audit infrastructure. These messages are now in /var/log/audit/audit.log. When auditd is not running, the kernel passes audit messages to syslog. These logs are typically kept in /var/log/messages and are viewable using dmesg. Audit extensions are now compiled into PAM. All programs that do grant entry to the system or change user account attributes will generate an audit message. To enable auditing within the kernel, you must pass the parameter audit=1 to the kernel during boot. Otherwise, you can use this command to enable auditing during run time: auditctl -e 1
LinuxThreads versus NPTL As the next step in removing support for the obsolete LinuxThreads library, code compiled and linked on &FC; &LOCALVER; now automatically uses the NPTL headers and libraries. In previous releases since &RHL; 9, the default threading was LinuxThreads since the interface is mostly forward compatible. The advantages of the NPTL interface is that the cancellation handling is faster (when -fexception is used, even in C code) and that the additional interfaces are now available without special compiler and linker parameters. In other words, you do not need to use and any longer. Note that lib{,64} is to be interpreted as lib64 on platforms which place DSOs in lib64/ directories, and lib/ otherwise. In &FC; &LOCALVER; it is still possible to create code using the LinuxThreads definitions. For this the linuxthreads-devel package must be installed and must be passed to the compiler. Previously, you could select the version of glibc and the libpgthread DSH using run time environment variables. You now need to also specify this variable in the environment: LD_LIBRARY_PATH=/lib{,64}/obsolete/linuxthreads This additional variable is required because the run/time libraries have been moved out of the way. There may be programs that will not work if the program uses an unfortunate DT_RPATH (which overwrites the LD_LIBRARY_PATH setting). All this makes it more cumbersome to run programs which depend on LinuxThreads. But this is intentional. Important FC5 will not have LinuxThreads support and all programs have to be converted to use NPTL by then. In general, conversion to using NPTL has not been an issue.
Enabling the <filename>slocate</filename> Database The database needed by the locate utility is no longer created by default. Enable the database creation by setting DAILY_UPDATE to in /etc/updatedb.conf if you want to use locate.
Stricter Controls in <filename>openssh</filename> The version of OpenSSH in &FC; &LOCALVER; is based on OpenSSH 3.9 and includes strict permission and ownership checks for the user configuration file ~/.ssh/config. If this file does not have appropriate ownership and permissions, ssh will exit. Check that ~/.ssh/config is owned by the owner of ~/, and that its permissions are set to mode 600. ls -l ~/.ssh/config -rw------- 1 username username 400 May 5 18:44 /home/username/.ssh/config The directory ~/ is command-line shorthand for the logged in user's home directory, usually /home/username/. In addition, OpenSSH is no longer configured to request X11 forwarding by default when connecting to servers. To enable X11 forwarding, the or option must be specified, or the option must be enabled in the ~/.ssh/config file. The behavior of ssh clients that are invoked with the option has changed. In OpenSSH 3.8 and later, X11 forwarding is performed in a way that applications run as untrusted clients by default. Previously, X11 forwarding was performed so that applications always ran as trusted clients. Some applications may not function properly when run as untrusted clients. To forward X11 so that applications are run as trusted clients, invoke ssh with the option instead of the option, or set in the file.
Perl Binary Compat Symlinks Binary compat symlinks for perl-5.8.0, perl-5.8.1, and perl-5.8.2 have been removed. If you have perl modules built with those older versions of perl, you need to rebuild using the perl-5.8.6 contained in &FC; &LOCALVER;.
&SERVER-TOOLS; &JAVA-PACKAGE;
Core This section contains the most elemental components of &DISTRO;, including the kernel.
yum The sqllite database is now used by yum, and makes performance noticeably faster. The Fedora Extras repository is now enabled by default.
&KERNEL; &SECURITY;
&DEVELOPMENT-TOOLS;
Language Support This section includes information related to the support of various languages under &DISTRO;.
The IIIMF Input System IIIMF is the Internet/Intranet Input Method Framework. In &FC; &LOCALVER; the iiimf package is updated to version 12.2. File Path Changes The names and locations of some files in the iiimf packages have changed. The IIIMF server has been renamed from /usr/sbin/htt to /usr/bin/iiimd, and the XIM bridge client renamed from httx to iiimx. The init.d script name has not changed: it is still called iiim. All the global system configuration files are now located under /etc/iiim/. Language Engine (LE) developers should note that LE modules and their data now live under ${libdir}/iiim/le/<LE_NAME>/, while runtime data is stored under /var/lib/iiim/le/<LE_NAME>/. For more information on the exact path and file location changes, please refer to Fedora IIIMF FAQ: http://www.fedora.redhat.com/projects/i18n/iiimf-faq.html. Hotkeys Trigger keys, such as CtrlSpace used to activate Input Methods, are now configurable with the command-line tool iiimf-le-tools. This feature is only supported by GTK2 applications currently. For other applications using XIM the trigger key can be changed using an X resource. Refer to the IIIMF FAQ at http://www.fedora.redhat.com/projects/i18n/iiimf-faq.html for more details on how to change trigger hotkeys. Note that the keyname refers to the X key symbol name. For example, if you want to activate with Ctrl@, you need to specify '<Control>at' as the keyname not '<Control>@'. The per-user configuration of hotkeys does not work currently with &SEL; in enforcing mode due to lack of &SEL; policy. In this case, the hotkey can only be changed in the system-wide configuration. Qt Support A Qt immodule for iiimf is now included. This immodule works but lacks a status window and is considered experimental. Therefore, the default for Qt applications is to continue using XIM for IIMF input. If you wish to try the immodule in a Qt application, first install the iiimf-qt package, start the application, then click mouse button-3 in an input area and select iiimqcf from the Select Input Method' submenu.
&PRINTING; &WEB-SERVERS; &SAMBA; &XORG;
--- NEW FILE printing-en.xml --- --- NEW FILE project-overview-en.xml ---
An Overview of the &PROJ; The goal of the &PROJ; is to work with the Linux community to build a complete, general-purpose operating system exclusively from open source software. Development is done in a public forum. The project produces time-based releases of &DISTRO; approximately 2-3 times a year, with a public release schedule. The &RH; engineering team continues to participate in building &DISTRO; and invites and encourages more outside participation than was possible in the past. By using this more open process, we hope to provide an operating system more in line with the ideals of free software and more appealing to the open source community. For more information, refer to the &PROJ; website: http://fedora.redhat.com/ In addition to the website, the following mailing lists are available: fedora-list at redhat.com — For users of &DISTRO; releases fedora-test-list at redhat.com — For testers of &DISTRO; test releases fedora-devel-list at redhat.com — For developers, developers, developers fedora-docs-list at redhat.com — For participants of the Documentation Project To subscribe to any of these lists, send an email with the word "subscribe" in the subject to <listname>-request (where <listname> is one of the above list names.) Alternately, you can subscribe through the Web interface: http://www.redhat.com/mailman/listinfo/ If you have subscribed in the past to rhl-list, rhl-beta-list, rhl-devel-list, or rhl-docs-list, your subscriptions have been retained. The &PROJ; also includes an IRC (Internet Relay Chat) channel. IRC is a real-time, text-based form of communication. With it, you can have conversations with multiple people in an open channel or chat with someone privately one-on-one. To talk with other &PROJ; participants via IRC, access freenode IRC network. Initially, you can use irc.freenode.net as the IRC server, although you may decide to select a server that is geographically closer to you. Refer to the freenode website (http://www.freenode.net/) for more information. &PROJ; participants frequent the #fedora channel, while &PROJ; developers can often be found on the #fedora-devel channel. Some of the larger projects may have their own channels as well; this information can be found on the project pages. In order to talk on the #fedora channel, you will need to register your nickname (nick). Instructions are given when you /join the channel. Note &RH; has no control over the &PROJ; IRC channels or their content.
--- NEW FILE samba-en.xml ---
Samba (Windows File System Compatibility) This section contains information related to Samba, the suite of software that enables Linux to interact with Microsoft Windows systems. Browsing of Windows shares (also known as SMB browsing) fails on &DISTRO; &DISTROVER; systems that have the standard firewall configured. This is most easily noticed in the failure of the desktop to display shares. The firewall disrupts the broadcast mode of SMB browsing, which is the default. There are two workarounds: Configure a WINS server on the network, and set the "wins server" option in smb.conf to the address of the WINS server. Disable the firewall. Disabling the firewall may make your system vulnerable Make sure you fully understand the risks before undertaking this step. For additional information, refer to the following bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133478
--- NEW FILE security-en.xml ---
Security This section highlights various security items from &FC;.
Digital Certificates Consolidated Digital certificates are now centralised in directories under /etc/pki/. Users performing an upgrade must relocate their digital certificates. OpenSSL: the /usr/share/ssl contents have moved to /etc/pki/tls and /etc/pki/CA. Dovecot: A dovecot-openssl.cnf file is automatically installed in /etc/pki/dovecot/. For information about &SEL;, refer to .
--- NEW FILE server-tools-en.xml ---
Server and System Configuration Tools This section highlights changes and additions to the various GUI server and system configuration tools in &FC;.
<application>system-config-lvm</application> The new LVM tool system-config-lvm assists you in managing logical volumes.
--- NEW FILE splash-en.xml ---
Welcome to &FC; &LOCALVER; &FC; is a completely free, user friendly, and secure general purpose platform based on Linux. The &FP; is an open source project that pioneers leading edge technology and concepts sponsored by &RH; and supported by the &FED; community. Latest Release Notes on the Web These release notes may be updated. Visit http://fedora.redhat.com/docs/release-notes/ to view the latest release notes for &DISTRO; &DISTROVER;. Refer to these webpages to find out more information about &FED;: — Technical release notes Help and Support (http://fedora.redhat.com/participate/communicate/) Participate in the &FP; (http://fedora.redhat.com/participate/) About the &FP; (http://fedora.redhat.com/about/)
New in &FC; &LOCALVER; &FC; &LOCALVER; is the latest version of the free and popular &FC; platform with a number of unique features and significant improvements over previous versions. This section provides an overview of the major highlights in this release. Desktop Enhancements — The &FED; desktop brings to you the latest software such as GNOME 2.10 and KDE 3.4 with a new look and feel. GNOME has the new simple and elegant Clearlooks default theme that is inspired by the classic Red Hat Bluecurve theme, as shown in . New desktop featuring Clearlooks and Evince Screenshot of Fedora desktop showing Firefox in the background and the new universal document viewer Evince in the foreground. Evince is displaying Lawrence Lessig's Free Culture. Improved Productivity Evince (http://www.gnome.org/projects/evince/) is a document viewer for multiple document formats such as pdf, postscript, and many others. Evince replaces a whole category of document viewers with a single simple application. OpenOffice.org 2.0 (http://www.openoffice.org/product2/index.html) is an office productivity suite. This latest version includes several enhancements such as improved Microsoft Office compatibility, completely revamped Impress presentation software, and native support for the OpenDocument format. This version also introduces Base, a fully integrated database management software. You can find the extensive list of new features at http://marketing.openoffice.org/2.0/featureguide.html. Eclipse 3.1 is an open and extensible software development platform that is an Integrated Development Environment (IDE) useful for programming in any language. Support for PowerPC (PPC) Architecture — Refer to and . Improved Security — &SEL; is a security architecture that protects applications and users through finely grained mandatory security controls. The default targeted policy has been improved to cover 80 additional daemons. You can read more in the technical release notes . Integrated Clustering Technology — Global File System (GFS) is an open source clustering file system that allows a cluster of Linux servers to share a common storage pool. &FC; &LOCALVER; has integrated GFS within the system to manage your storage in an efficient way. You can read more at http://www.redhat.com/software/rha/gfs/ and http://www.redhat.com/docs/manuals/enterprise/. Built-in Virtualization — Xen is a virtual machine that can securely run multiple operating systems in their own sandboxed domains. Xen has been integrated into &FC; to work in a seamless fashion. You can read more about Xen at http://fedora.redhat.com/projects/virtualization/. Solid Platform — &FC; &LOCALVER; includes and integrates the latest 4.0 version of GNU Compiler Collection, which has a rewritten optimization infrastructure and improved support for a native open source Java software stack. This stack includes parts of OpenOffice.org 2.0., Eclipse, and Apache Jakarta, among others.
MP3 Codecs and Other Patented or Closed Source Software This section is a brief explanation of why certain software is not included in &FC; or &FEX;. This information was drawn directly from the canonical wiki page: http://fedoraproject.org/wiki/ForbiddenItems A frequent question of the &FP; is why certain items are not included in &FC; or &FEX;. This briefly explains some of the reasons. Other items, such as file systems support, requires community participation. For more information, refer to http://fedoraproject.org/wiki/Wishlist NTFS NTFS Support is not included in the &FC; kernel because of patent concerns. Using a file system natively supported by Linux such as ext3 is a better option. If you must share files between Windows and Linux on a single system, use FAT/FAT32 (vfat) instead. For sharing across a network, Samba is a good option. MP3 encode/decode functionality MP3 support is not included in any &FC; application because MP3 is heavily patented in several regions including the United States. The patent holder is unwilling to give an unrestricted patent grant, as required by the GPL. Other platforms might have paid the royalty and/or included proprietary software. Other Linux distributions not based in a region affected by the patent might ship MP3 decoders/encoders. However, &FC; cannot and does not ship MP3 decoders/encoders in order to serve the goal of shipping only free and open source software. Using other open source formats such as Ogg Vorbis (a lossy codec that has better quality than MP3) or FLAC (a lossless codec) is highly recommended. NVIDIA 3D drivers The NVIDIA 3D drivers are closed source. &FC; does not include proprietary binaries. Consider using an Intel or any other manufacturer that supports open source cards with full specifications and/or source code. ATI 3D drivers The ATI 3D drivers are closed source. &FC; does not include proprietary binaries. Consider using an Intel or any other manufacturer that supports open source cards with full specifications and/or source code. RealPlayer RealPlayer is a closed source application. &FC; does not include proprietary binaries. Consider using open source codecs that do not have patent restrictions. DVD video playback DVD video playback (of CSS encrypted DVDs) may violate the US DMCA (refer to http://en.wikipedia.org/wiki/DMCA) because it may be considered circumventing an encryption mechanism. Additionally, MPEG2 is a patented codec, so even DVDs without encryption cannot be played. Consider using open source unencrypted mediums such as Ogg Theora formats. Mono Mono packages are not currently included due to potential legal issues. (Pending more input.) Applications can be written in other languages that are open source, such as Python, Perl, or Ruby. Java is cross-platform and GCJ is a relatively mature open source implementation of it. These are not direct one-to-one equivalents with .NET but might serve your purpose. Cryptology (mcrypt) Some cryptology related packages such as mcrypt are not included within &FC; due to US export restrictions. Consider using non-restricted cryptographical methods instead. szip The szip license is too restrictive for inclusion in &FEX;. Use other open source alternatives. In conclusion: If it is proprietary, it cannot be included in &FED;. If it is legally encumbered, it cannot be included in &FED;. If it violates US Federal law, it cannot be included in &FED;. Of course, the logical followup is: "But I want to get foo and do bar, how can I do one of the items listed above?" The unofficial http://fedorafaq.org provides useful answers on commonly asked questions. However, these are completely unsupported by the &FP;. The &FP; encourages using free and open source software. The binary only drivers can be acquired from the vendors. You can find many interesting things with Google.
--- NEW FILE web-servers-en.xml ---
Web Servers This section contains information on Web-related applications.
<filename>mod_perl</filename> The RC5 release of mod_perl 2.0 is now included. The API provided by this release is incompatible with previous 1.99_xx releases. Please refer to the following document for a discussion of how to adapt code to use the new API: http://perl.apache.org/docs/2.0/rename.html
<filename>php</filename> Version 5.0 of PHP is now included, which includes a number of changes to the language along with significant performance improvements. Please refer to the PHP documentation for more information on migrating from PHP 4.3 to PHP 5.0: http://www.php.net/manual/en/migration5.php The /usr/bin/php binary is now built using the CLI command-line SAPI, rather than the CGI SAPI. Use /usr/bin/php-cgi for CGI SAPI. The php-cgi also includes FastCGI support. The following extensions have been added: The mysqli extension, a new interface designed specifically for MySQL 4.1. This is included in the php-mysql package. The soap extension, for implementing SOAP clients and servers. The following extensions are now available as optional loadable extensions, rather than being built in to the PHP binaries: The dba extension, now available in the php-dba package The bcmath extension, now available in the php-bcmath package
--- NEW FILE xorg-en.xml ---
X Window System (Graphics) This section contains information related to the X Window System implementation provided with &DISTRO;.
<filename>xorg-x11</filename> Users new to the X.org X11 implementation should take note of a few differences between it and the XFree86.org X11 implementation which shipped in previous &RH; and &FED; operating systems. In particular, the names of some files have changed: X Server Binary: XFree86 X11: XFree86 X.org X11: Xorg X Server Configuration File: XFree86 X11: /etc/X11/XF86Config X.org X11: /etc/X11/xorg.conf X Server Log File: XFree86 X11: /var/log/XFree86.$DISPLAY.log X.org X11: /var/log/Xorg.$DISPLAY.log When configuring or troubleshooting your X server configuration, be sure that you are using the correct files. There has been some confusion regarding font-related issues under the X Window System in recent versions of &DISTRO; (and versions of &RHL; before it.) At the present time, there are two font subsystems, each with different characteristics: The original (15+ year old) subsystem is referred to as the core X font subsystem. Fonts rendered by this subsystem are not anti-aliased, are handled by the X server, and have names such as: -misc-fixed-medium-r-normal--10-100-75-75-c-60-iso8859-1 The newer font subsystem is known as fontconfig, and allows applications direct access to the font files. Fontconfig is often used along with the Xft library, which allows applications to render fontconfig fonts to the screen with antialiasing. Fontconfig uses more human-friendly names such as: Luxi Sans-10 Over time, fontconfig and Xft will replace the core X font subsystem. At the present time, applications using the Qt 3 or GTK 2 toolkits (which would include KDE and GNOME applications) use the fontconfig and Xft font subsystem; almost everything else uses the core X fonts. In the future, &FC; may support only fontconfig/Xft in place of the XFS font server as the default local font access method. Note An exception to the font subsystem usage outlined above is OpenOffice.org, which uses its own font rendering technology. The steps to add new fonts to &DISTRO; &DISTROVER; depend on the fonts subsystem this is going to use the new fonts. For the core X font subsystem: Create the /usr/share/fonts/local/ directory (if it doesn't already exist): mkdir /usr/share/fonts/local/ Copy the new font file into /usr/share/fonts/local/ Update the font information by issuing the following commands (note that, due to formatting restrictions, the following commands may appear on more than one line; in use, each command should be entered on a single line): ttmkfdir -d /usr/share/fonts/local/ -o /usr/share/fonts/local/fonts.scale mkfontdir /usr/share/fonts/local/ If you had to create /usr/share/fonts/local/, you must then add it to the X font server (xfs) path: chkfontpath --add /usr/share/fonts/local/ Adding new fonts to the fontconfig font subsystem is more straightforward; the new font file only needs to be copied into the /usr/share/fonts/ directory (individual users can modify their personal font configuration by copying the font file into the ~/.fonts/ directory). After the new font has been copied, use fc-cache to update the font information cache: fc-cache <directory> (Where <directory> would be either the /usr/share/fonts/ or ~/.fonts/ directories.) Individual users may also install fonts graphically, by browsing fonts:/// in Nautilus, and dragging the new font files there. Note If the font filename ends with ".gz", it has been compressed with gzip, and must be decompressed (with the gunzip command) before the fontconfig font subsystem can use the font. Due to the transition to the new font system based on fontconfig/Xft, GTK+ 1.2 applications are not affected by any changes made via the Font Preferences dialog. For these applications, a font can be configured by adding the following lines to the file ~/.gtkrc.mine: style "user-font" { fontset = "<font-specification>" } widget_class "*" style "user-font" (Where <font-specification> represents a font specification in the style used by traditional X applications, such as "-adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-*".)
Index: fedora.css =================================================================== RCS file: /cvs/docs/release-notes/fedora.css,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- fedora.css 24 Oct 2005 13:13:33 -0000 1.1 +++ fedora.css 25 Oct 2005 02:48:50 -0000 1.2 @@ -39,8 +39,8 @@ div.note table, div.tip table, div.important table, div.caution table, div.warning table { width: 95%; - border: 2px solid #B0C4DE; - background-color: #F0F8FF; + border: 2px solid #D0D0B0; + background-color: #FAF9E0; color: #000000; /* padding inside table area */ padding: 0.5em; @@ -72,21 +72,31 @@ h1, h2, h3, h4 { font-family: luxi sans,sans-serif; - color: #990000; + color: #22437f; font-weight: bold; } h1 { font-size: 1.75em; } - + h2 { font-size: 1.25em; } - + h3 { font-size: 1.1em; } +a:link { + color: #900; +} +a:visited { + color: #48468f; +} +a:hover { + color: #f20; +} + code.screen, pre.screen { font-family: monospace; font-size: 1em; @@ -108,9 +118,17 @@ } .procedure ol li { - margin-bottom: 1.5em; + margin-bottom: 0.5em; } -/* prevent inheritance */ .procedure ol li li { + /* prevent inheritance */ + margin-bottom: 0em; +} + +.itemizedlist ul li { + margin-bottom: 0.5em; +} +.itemizedlist ul li li { + /* prevent inheritance */ margin-bottom: 0em; } --- daemons.xml DELETED --- --- database-servers.xml DELETED --- --- desktop.xml DELETED --- --- development-tools.xml DELETED --- --- feedback.xml DELETED --- --- file-servers.xml DELETED --- --- file-systems.xml DELETED --- --- hardware-reqs.xml DELETED --- --- install-notes.xml DELETED --- --- intro.xml DELETED --- --- java-package.xml DELETED --- --- kernel.xml DELETED --- --- misc-server.xml DELETED --- --- multimedia.xml DELETED --- --- networking.xml DELETED --- --- overview.xml DELETED --- --- package-movement.xml DELETED --- --- package-notes.xml DELETED --- --- printing.xml DELETED --- --- project-overview.xml DELETED --- --- samba.xml DELETED --- --- security.xml DELETED --- --- server-tools.xml DELETED --- --- splash.xml DELETED --- --- web-servers.xml DELETED --- --- xorg.xml DELETED --- From fedora-docs-commits at redhat.com Tue Oct 25 08:34:03 2005 From: fedora-docs-commits at redhat.com (Karsten Wade (kwade)) Date: Tue, 25 Oct 2005 04:34:03 -0400 Subject: release-notes entertainment-en.xml, NONE, 1.1 i18n-en.xml, NONE, 1.1 legacy-en.xml, NONE, 1.1 Makefile, 1.2, 1.3 RELEASE-NOTES-en.xml, 1.2, 1.3 daemons-en.xml, 1.1, 1.2 desktop-en.xml, 1.1, 1.2 development-tools-en.xml, 1.1, 1.2 file-servers-en.xml, 1.1, 1.2 install-notes-en.xml, 1.1, 1.2 java-package-en.xml, 1.1, 1.2 kernel-en.xml, 1.1, 1.2 multimedia-en.xml, 1.1, 1.2 networking-en.xml, 1.1, 1.2 package-movement-en.xml, 1.1, 1.2 package-notes-en.xml, 1.1, 1.2 security-en.xml, 1.1, 1.2 server-tools-en.xml, 1.1, 1.2 splash-en.xml, 1.1, 1.2 web-servers-en.xml, 1.1, 1.2 xorg-en.xml, 1.1, 1.2 Message-ID: <200510250834.j9P8Y3rg022299@cvs-int.fedora.redhat.com> Author: kwade Update of /cvs/docs/release-notes In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv22258 Modified Files: Makefile RELEASE-NOTES-en.xml daemons-en.xml desktop-en.xml development-tools-en.xml file-servers-en.xml install-notes-en.xml java-package-en.xml kernel-en.xml multimedia-en.xml networking-en.xml package-movement-en.xml package-notes-en.xml security-en.xml server-tools-en.xml splash-en.xml web-servers-en.xml xorg-en.xml Added Files: entertainment-en.xml i18n-en.xml legacy-en.xml Log Message: All of the content from the Wiki has been incorporated, some other changes, cautions and such applied, this is truly a test release notes with some poor language and other lack of polish. --- NEW FILE entertainment-en.xml ---
Games and Entertainment &FC; and &FEX; provide a selection of games that cover a variety of genres. By default, &FC;includes a small package of games for GNOME (called gnome-games). For a list of other games that are available for installation through yum, open a terminal and enter the following command: yum groupinfo "Games and Entertainment" For help using yum to install the assorted game packages, refer to the guide available at: http://fedora.redhat.com/docs/yum/
--- NEW FILE i18n-en.xml ---
Internationalization (i18n) SCIM has replaced all the other input methods. Major highlight.
Language Support This section includes information related to the support of various languages under &DISTRO;.
The IIIMF Input System IIIMF is the Internet/Intranet Input Method Framework. In &FC; &LOCALVER; the iiimf package is updated to version 12.2. File Path Changes The names and locations of some files in the iiimf packages have changed. The IIIMF server has been renamed from /usr/sbin/htt to /usr/bin/iiimd, and the XIM bridge client renamed from httx to iiimx. The init.d script name has not changed: it is still called iiim. All the global system configuration files are now located under /etc/iiim/. Language Engine (LE) developers should note that LE modules and their data now live under ${libdir}/iiim/le/<LE_NAME>/, while runtime data is stored under /var/lib/iiim/le/<LE_NAME>/. For more information on the exact path and file location changes, please refer to Fedora IIIMF FAQ: http://www.fedora.redhat.com/projects/i18n/iiimf-faq.html. Hotkeys Trigger keys, such as CtrlSpace used to activate Input Methods, are now configurable with the command-line tool iiimf-le-tools. This feature is only supported by GTK2 applications currently. For other applications using XIM the trigger key can be changed using an X resource. Refer to the IIIMF FAQ at http://www.fedora.redhat.com/projects/i18n/iiimf-faq.html for more details on how to change trigger hotkeys. Note that the keyname refers to the X key symbol name. For example, if you want to activate with Ctrl@, you need to specify '<Control>at' as the keyname not '<Control>@'. The per-user configuration of hotkeys does not work currently with &SEL; in enforcing mode due to lack of &SEL; policy. In this case, the hotkey can only be changed in the system-wide configuration. Qt Support A Qt immodule for iiimf is now included. This immodule works but lacks a status window and is considered experimental. Therefore, the default for Qt applications is to continue using XIM for IIMF input. If you wish to try the immodule in a Qt application, first install the iiimf-qt package, start the application, then click mouse button-3 in an input area and select iiimqcf from the Select Input Method' submenu.
--- NEW FILE legacy-en.xml --- Index: Makefile =================================================================== RCS file: /cvs/docs/release-notes/Makefile,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- Makefile 24 Oct 2005 14:08:53 -0000 1.2 +++ Makefile 25 Oct 2005 08:34:00 -0000 1.3 @@ -12,7 +12,7 @@ # LANGUAGES = en DOCBASE = RELEASE-NOTES -XMLEXTRAFILES-en=daemons.xml database-servers.xml desktop.xml development-tools.xml feedback.xml file-servers.xml file-systems.xml hardware-reqs.xml install-notes.xml intro.xml java-package.xml kernel.xml misc-server.xml multimedia.xml networking.xml overview.xml package-movement.xml package-notes.xml printing.xml project-overview.xml samba.xml security.xml server-tools.xml splash.xml web-servers.xml xorg.xml +XMLEXTRAFILES-en=daemons-en.xml database-servers-en.xml desktop-en.xml development-tools-en.xml feedback-en.xml file-servers-en.xml file-systems-en.xml hardware-reqs-en.xml install-notes-en.xml intro-en.xml java-package-en.xml kernel-en.xml misc-server-en.xml multimedia-en.xml networking-en.xml overview-en.xml package-movement-en.xml package-notes-en.xml printing-en.xml project-overview-en.xml samba-en.xml security-en.xml server-tools-en.xml splash-en.xml web-servers-en.xml xorg-en.xml # ###################################################### include ../docs-common/Makefile.common Index: RELEASE-NOTES-en.xml =================================================================== RCS file: /cvs/docs/release-notes/RELEASE-NOTES-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- RELEASE-NOTES-en.xml 24 Oct 2005 13:33:23 -0000 1.2 +++ RELEASE-NOTES-en.xml 25 Oct 2005 08:34:00 -0000 1.3 @@ -3,57 +3,59 @@ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [ - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + - -%FEDORA-ENTITIES-EN; - - - - - - - - - - - - - + + %FEDORA-ENTITIES-EN; + + + + + + + + + + + + + ]> -
- &DISTRO; &DISTROVER; Release Notes <emphasis>(updated)</emphasis> + &DISTRO; &DISTROVER; Release Notes 2005 &FORMAL-RHI; @@ -70,12 +72,7 @@ &OVERVIEW; &INSTALL-NOTES; &PACKAGE-NOTES; + &LEGACY; &PACKAGE-MOVEMENT; &PROJECT-OVERVIEW; -
Index: daemons-en.xml =================================================================== RCS file: /cvs/docs/release-notes/daemons-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- daemons-en.xml 25 Oct 2005 02:48:50 -0000 1.1 +++ daemons-en.xml 25 Oct 2005 08:34:00 -0000 1.2 @@ -1,23 +1,33 @@ -
- System Services - -
- <filename>cron</filename> and <filename>slocate</filename> - - The updatedb utility is no longer - automatically run by cron to create and - update the database of files used by slocate. - Updating this database is an intensive process that users of - workstations and laptops may find disruptive. - - To enable daily updates of the slocate - database, edit the file /etc/updatedb.conf as follows: - +
+ System Services + + Information Out-of-Date + + The content in this section needs to be updated for &DISTRO; + &DISTROVER; + + +
+ <filename>cron</filename> and + <filename>slocate</filename> + + The updatedb utility is no longer automatically + run by cron to create and update the database + of files used by slocate. Updating this + database is an intensive process that users of workstations and + laptops may find disruptive. + + + To enable daily updates of the slocate + database, edit the file /etc/updatedb.conf as + follows: + - -DAILY_UPDATE=yes - - + + DAILY_UPDATE=yes + +
+
+ Index: desktop-en.xml =================================================================== RCS file: /cvs/docs/release-notes/desktop-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- desktop-en.xml 25 Oct 2005 02:48:50 -0000 1.1 +++ desktop-en.xml 25 Oct 2005 08:34:00 -0000 1.2 @@ -1,3 +1,73 @@ +
+ Desktop + + Notes + + GNOME 2.12 and KDE 3.4.2 Major highlight + + + + The current test release has GNOME 2.12.1, together with + some previews of technology from the forthcoming GNOME 2.14: + + + + gnome-power-manager: brings the Hardware Abstraction + Layer to the world of laptop batteries and UPS units - these + things should "Just Work", with a simple UI (naturally, in + a test release, they might not) + + + + gnome-screensaver: giving a fresh UI to screensavers and + the Lock Screen dialog + + + + Memory optimizations in the fontconfig and + shared-mime-info packages (these now use shared + memory-mapped caches for this data). Both of these caches + are still somewhat experimental. + + + + + + Test feedback on these experimental packages is especially + appreciated. + + + GNOME 2.12 has removed the terminal option from the desktop root + menu. nautilus-open-terminal in Fedora Extras repository provides a + enhanced replacement. It is also mentioned in the GNOME 2.12 release + notes itself but we might highlight it since the package is provided + with the extras repository. + + + Screensavers not installed by default anymore. Should explain why + and provide commands to install them. + + MCS SELinux is in rawhide. Major highlight + (tentative - not sure about classification of + this change) + + + OpenOffice and upgrading from test releases + + If you choose to go counter to the recommendation to not upgrade from a previous test + release, you may encounter a problem with OpenOffice following the upgrade. + + + To resolve this, you must do the following command before doing the upgrade: + + +rm -rf /usr/lib/openoffice.org*/share/template/*/wizard/bitmap + + +
+ The DVD or first CD of the - installation set of &FC; is set to be bootable on the Apple Macintosh and should boot - the appropriate 32-bit or 64-bit installer. In addition, bootable - CD images can be found in the images/ - directory of the DVD or first CD. Choose the appropriate - boot.iso according to the hardware: + The DVD or first CD of the installation set of &FC; is set to be + bootable on supported hardware. In addition, bootable CD images + can be found in the images/ directory of the + DVD or first CD. These will behave differently according to the + hardware: - - - images/mac/boot.iso - 32-bit - Apple Macintosh - (G3/G4) - - - - - images/mac64/boot.iso - 64-bit Apple Macintosh (G5) - - - - images/pseries/boot.iso - 64-bit - IBM - eServer pSeries - (POWER4/POWER5) - - - - - Power management - support, including sleep and backlight level management, is - present in the apmud package, which is in - &FEX;. &FEX; for &FC; is configured by default for - yum. Following installation, - apmud can be installed by running - yum install apmud. - - - + + Boot Image Behavior by Hardware + + Apple Macintosh + + The bootloader should automatically boot the appropriate + 32-bit or 64-bit installer. Power management support, + including sleep and backlight level management, is present + in the apmud package, which is in &FEX;. + &FEX; for &FC; is configured by default for yum. Following + installation, apmud can be installed by + running the command yum install apmud + in a terminal. + + + + + 64-bit IBM eServer pSeries (POWER4/POWER5) + + After using OpenFirmware to boot the CD, the bootloader + (yaboot) should automatically boot the + 64-bit installer. + + + + + 32-bit CHRP (IBM RS/6000 and others) + + After using OpenFirmware to boot the CD, select the + linux32 boot image at the + boot: prompt to start the 32-bit installer. + Otherwise, the 64-bit installer is started, which does not + work. + + + + Genesi Pegasos II + + As of &DISTRO; &DISTROVER;, firmware with full support + for ISO9660 file systems is not yet released for the + Pegasos. However, the network boot image can be used. At + the OpenFirmware prompt, enter the command: + +boot cd: /images/netboot/ppc32.img + + + You will also need to configure OpenFirmware on the Pegasos + manually to make the installed &FC; system bootable. To do + this, you need to set the boot-device and + boot-file environment variables + appropriately. + + + + + Network booting + + There are combined images containing the installer + kernel and ramdisk in the images/netboot/ directory of the + install tree. These are intended for network booting with + TFTP, but can be used in many ways. + + + The command yaboot supports tftp + booting for IBM eServer pSeries and Apple Macintosh. + &FED; recommends using yaboot over the netboot images. + + + +
Anaconda Notes Index: java-package-en.xml =================================================================== RCS file: /cvs/docs/release-notes/java-package-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- java-package-en.xml 25 Oct 2005 02:48:50 -0000 1.1 +++ java-package-en.xml 25 Oct 2005 08:34:00 -0000 1.2 @@ -1,5 +1,12 @@ -
+
Java Package Recommendations + + Information Out-of-Date + + The content in this section needs to be updated for &DISTRO; + &DISTROVER; + + &FC; &LOCALVER; users are advised not to use the Java RPM provided by Sun. It contains Provides that @@ -10,8 +17,8 @@ &FC; &LOCALVER; users should use either the RPM from jpackage.org or manually install the Sun Java tarball into - /opt. Sun Java 1.5+ is recommended for - stability purposes. + /opt.
up2date --get-source kernel @@ -166,16 +159,16 @@ Install - kernel-<version>.src.rpm - using the command: + kernel-version.src.rpm + using the command: -rpm -Uvh kernel-<version>.src.rpm +rpm -Uvh kernel-version.src.rpm This writes the RPM contents into - /usr/src/redhat/SOURCES and - /usr/src/redhat/SPECS. + /usr/src/redhat/SOURCES and + /usr/src/redhat/SPECS. @@ -187,57 +180,73 @@ rpmbuild -bp --target $(arch) kernel-2.6.spec - The kernel source tree will be located in the - /usr/src/redhat/BUILD/kernel-<version> - directory. It is common practice to move the resulting - linux-<version> - directory to the /usr/src tree; while not - strictly necessary, we suggest that you do this to match the - generally-available documentation. + The kernel source tree is located in the + /usr/src/redhat/BUILD/kernel-version + directory. It is common practice to move the resulting + linux-version + directory to the /usr/src tree; while not + strictly necessary, doing so matches you with the + generally-available documentation. -cd /usr/src/redhat/BUILD/kernel-<version> /usr/src/ -mv linux-<version> /usr/src/ +cd /usr/src/redhat/BUILD/kernel-version /usr/src/ +mv linux-version /usr/src/ cd /usr/src -ln -s ./linux-<version> linux +ln -s ./linux-version linux cd /usr/src/linux The configurations for the specific kernels shipped in - &DISTRO; &DISTROVER; are in the configs/ - directory. For example, the i686 SMP configuration file is - named - configs/kernel-<version>-i686-smp.config. - Issue the following command to place the desired configuration - file in the proper place for building: + &DISTRO; &DISTROVER; are in the configs/ + directory. For example, the i686 SMP configuration file is + named + configs/kernel-version-i686-smp.config. + Issue the following command to place the desired configuration + file in the proper place for building: -cp configs/<desired-config-file> .config +cp configs/desired-config-file .config - You can also find the .config file that matches your current kernel configuration in the /lib/modules/<version>/build/.config file. + You can also find the .config file that + matches your current kernel configuration in the + /lib/modules/version/build/.config + file. - Every kernel gets a name based on its version number. - This is the value the uname -r command displays. - The kernel name is defined by the first four lines of the kernel Makefile. - To protect the innocent, the Makefile has been changed to generate a kernel with a different name from that of the running kernel. - Before a module can be accepted by the running kernel, that - module must have been compiled for a kernel with the correct - name. To do this, you must edit the kernel Makefile - - - For example, if the uname -r returns the string 2.6.11-1.234_FC4, change the EXTRAVERSION definition from this: - - EXTRAVERSION = -prep - to this: - EXTRAVERSION = -1.234_FC4 + Every kernel gets a name based on its version number. This is + the value the uname -r command displays. + The kernel name is defined by the first four lines of the + kernel Makefile. To protect the innocent, + the Makefile has been changed to generate + a kernel with a different name from that of the running + kernel. Before a module can be accepted by the running kernel, + that module must have been compiled for a kernel with the + correct name. To do this, you must edit the kernel + Makefile + + + For example, if the uname -r returns the + string 2.6.11-1.234_FC4, change the + EXTRAVERSION definition + from this: + + +EXTRAVERSION = -prep + + + to this: + + +EXTRAVERSION = -1.234_FC4 + - that is, substitute everything from the final dash onward. + That is, substitute everything from the final dash onward. @@ -287,13 +296,12 @@ utilities, such as management daemons. Consequently, to remove such a kernel, perhaps after an update, you cannot simply use the rpm -e - kernel-<version> - command as in earlier distributions because these user space - packages depend on the kernel package. You may either list both - the kernel package and its user space dependent packages on the - rpm -e command, or you may wish to use the - yum remove - kernel-<version> + kernel-version command as + in earlier distributions because these user space packages depend + on the kernel package. You may either list both the kernel package + and its user space dependent packages on the rpm + -e command, or you may wish to use the yum + remove kernel-version command instead since yum automatically removes dependent packages if necessary. Index: multimedia-en.xml =================================================================== RCS file: /cvs/docs/release-notes/multimedia-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- multimedia-en.xml 25 Oct 2005 02:48:50 -0000 1.1 +++ multimedia-en.xml 25 Oct 2005 08:34:00 -0000 1.2 @@ -1,9 +1,99 @@
Multimedia - This section contains information related to multimedia - applications. + &FC; includes applications for assorted multimedia functions, + including playback, recording, and editing. Additional packages are + available through the &FEX; repository. + + + Multimedia Players + + By default, &FC; installs with + rhythmbox, totem, + and Helix Player + (hxplay) for media playback. In addition, + many other programs are available in the &FC; and &FEX; + repositories, including the popular xmms package. Both GNOME + and KDE also have specific sets of programs that can be used + with a variety of formats. Other popular programs, such as + Adobe/Macromedia's Flash Player, Real Player, VLC, MPlayer, + and Xine, can also be installed, but are excluded from the + &FED; repositories since they are not compatible with &FED;'s + licensing or are usually distributed with support for + restricted formats. For more on this, refer to . + + + &FC; is also equipped to take full advantage of the Advanced + Linux Sound Architecture (ALSA) sound system. This means that + many programs can play sound simultaneously, which was once + difficult on Linux systems. When all multimedia software is + configured to use ALSA for sound support, this old limitation + disappears. For more information about ALSA, visit the + project website: + + + http://www.alsa-project.org/ + + + + + Ogg and Xiph.Org Foundation Formats + + Fedora includes complete support for the Ogg media + container format, the Vorbis audio, Theora video, Speex audio, + and FLAC lossless audio formats. More information on these + formats and how to use them can be found at the Xiph.Org + Foundation's web site: + + + http://www.xiph.org/ + + + + + MP3 & DVD Support + + &FC; and &FEX; cannot include support for MP3 or DVD + playback or recording, because the MP3 and MPEG (DVD) formats + are patented, and the patent owners have not provided the + necessary licenses. For more information, refer to . + + + + +
+ Excluded Multimedia Software + + Several programs are excluded from &FC; and &FEX; due to licensing + issues. These include programs that provide MP3 and DVD support, + Flash Player and Real Player. Users who wish to use these + programs or restricted formats have to acquire additional + packages from third-party repositories. Many of the multimedia + applications in the Fedora repositories support plugins, so + support for new formats can be easily added or removed. For more + on this subject, please see: + + + http://fedoraproject.org/wiki/ForbiddenItems + +
+
+ CD and DVD Authoring and Burning + + Tools are included in &FC; and &FEX; for easily mastering and + burning CDs and DVDs. Tools that can be used from the console + include cdrecord, readcd, + mkisofs, and other typical Linux applications. + For GNOME users, the xcdroast package from + &FC; and the graveman package from &FEX; + allow easy preparation of audio and data discs. For KDE users, + the k3b package provides a very robust tool + for these tasks. + +
-
- Packages Moved to &FEX; - - These are some of the packages that have moved from &CORE; to - &FEX;. These are active packages that are maintained and - supported by the &FP;. If you are looking for information about - &EX;, refer to this URL: + + This command was used to generate the list of package changes. The + backslash \ is used to artificially + break the line for printing purposes.: + + +treediff.py dist-fc4 dist-rawhide > /tmp/diff \ +sed -e 's,^,* ,g' -e 's,$,\n,g' /tmp/diff > diffwiki + +
+ Package Changes + As of 21st September 2005 + [106429] MAKEDEV-3.19-1 -> [115423] MAKEDEV-3.19-4 + [111566] ImageMagick-6.2.2.0-2 -> [112246] + ImageMagick-6.2.2.0-4 + [105261] newt-0.51.6-7 -> [117695] newt-0.51.6-8 + [106878] am-utils-6.0.9-12 -> [117066] am-utils-6.1.1-2 - - http://fedoraproject.org/wiki/Extras + [108819] amanda-2.4.5-2 -> [115871] amanda-2.4.5-3 + [112105] anaconda-10.2.1.5-2 -> [118390] + anaconda-10.3.0.24-1 + [105300] aspell-0.50.5-6 -> [114172] aspell-0.60.3-2 + [108035] aspell-ca-0.50-2 -> [114184] aspell-ca-0.50-4 + + [108036] aspell-cs-0.51-2 -> [114270] aspell-cs-0.51-3 + + [108038] aspell-da-0.50-11 -> [114276] aspell-da-0.50-12 + + [106443] libsoup-2.2.3-2 -> [116988] libsoup-2.2.6.1-1 + + [108042] aspell-es-0.50-11 -> [117058] aspell-es-0.50-13 + + [108044] aspell-fr-0.50-8 -> [114285] aspell-fr-0.50-9 + + [108051] aspell-it-0.53-2 -> [114362] aspell-it-0.53-3 + + [108055] aspell-nl-0.50-6 -> [114363] aspell-nl-0.50-7 + + [108058] aspell-no-0.50.1-8 -> [114366] aspell-no-0.50.1-9 + + [108060] aspell-pl-0.51-3 -> [118018] aspell-pl-0.51-5 + + [108061] aspell-sv-0.50-7 -> [114371] aspell-sv-0.50-8 + + [107959] at-3.1.8-77_FC4 -> [112026] at-3.1.8-78 + [108132] gtkhtml3-3.6.2-1 -> [117587] gtkhtml3-3.8.0-1 + + [108304] ntp-4.2.0.a.20040617-8 -> [117060] + ntp-4.2.0.a.20050816-1 + [108909] autofs-4.1.4-5 -> [112718] autofs-4.1.4-9 + [102923] automake-1.9.5-1 -> [114414] automake-1.9.6-1 + + [108562] autorun-3.16-1 -> [118091] autorun-3.17-1 + [105321] awesfx-0.5.0d-2 -> [113536] awesfx-0.5.0d-3 + [105808] nut-2.0.1-1 -> [114509] nut-2.0.2-1 + [110344] bash-3.0-31 -> [118423] bash-3.0-34 + [110908] bind-9.3.1-4 -> [116915] bind-9.3.1-11 + [111486] binutils-2.15.94.0.2.2-2 -> [116754] + binutils-2.16.91.0.2-4 + [105319] bootparamd-0.17-22.devel -> [116780] + bootparamd-0.17-23.devel + [106988] bug-buddy-2.10.0-1 -> [117633] bug-buddy-2.12.0-1 + + [111028] bzip2-1.0.2-16 -> [117182] bzip2-1.0.3-1 + [106470] pax-3.0-11 -> [116422] pax-3.4-1 + [109185] SysVinit-2.85-39 -> + [113360] SysVinit-2.85-40 + [111393] control-center-2.10.1-6 -> [118105] + control-center-2.12.0-2 + [111120] openldap-2.2.23-5 -> [111936] openldap-2.2.26-1 + + [110745] cpio-2.6-7 -> [113389] cpio-2.6-8 + [106419] cracklib-2.8.2-1 -> [111862] cracklib-2.8.3-1 + + [104496] bluez-hcidump-1.18-1 -> [115995] + bluez-hcidump-1.24-1 + [104877] ctags-5.5.4-3 -> [115419] ctags-5.5.4-4 + [108614] cvs-1.11.19-8 -> [116935] cvs-1.11.19-10 + [108252] cyrus-sasl-2.1.20-5 -> [117833] cyrus-sasl-2.1.21-5 + + [109650] pam-0.79-8 -> [118330] pam-0.80-8 + [109663] dhcp-3.0.2-12 -> [117972] dhcp-3.0.3-6 + [110743] apr-0.9.6-3 -> [118164] apr-0.9.6-6 + [110347] e2fsprogs-1.37-4 -> [117739] e2fsprogs-1.38-1 + + [104668] diffstat-1.38-2 -> [116208] diffstat-1.38-4 + [107298] doxygen-1.4.2-1 -> [118248] doxygen-1.4.4-2 + [110505] dump-0.4b40-2 -> [113542] dump-0.4b40-4 + [110508] eject-2.0.13-15 -> [117061] eject-2.1.2-1 + [110262] parted-1.6.22-2 -> [117238] parted-1.6.24-1 + [110911] emacs-21.4-5 -> [114092] emacs-21.4-7 + [111808] esound-0.2.35-5 -> [114327] esound-0.2.36-1 + [105304] passwd-0.69-2 -> [112701] passwd-0.70-1 + [106286] fetchmail-6.2.5-7 -> [114678] fetchmail-6.2.5.2-1 + + [109759] patch-2.5.4-24 -> [117794] patch-2.5.4-29 + [111272] filesystem-2.3.4-1 -> [116817] filesystem-2.3.5-1 + + [106330] findutils-4.2.20-1 -> [117490] findutils-4.2.25-2 + + [105012] finger-0.17-28 -> [113967] finger-0.17-29 + [105097] freetype-2.1.9-2 -> [116586] freetype-2.1.9-4 + + [111401] ftp-0.17-26 -> [117241] ftp-0.17-29 + [104499] gawk-3.1.4-5 -> [118359] gawk-3.1.5-2 + [111099] gcc-4.0.0-8 -> [118294] gcc-4.0.1-14 + [108458] gd-2.0.33-2 -> [117628] gd-2.0.33-3 + [109684] gdb-6.3.0.0-1.21 -> [117661] gdb-6.3.0.0-1.65 + + [106626] gettext-0.14.3-1 -> [116274] gettext-0.14.5-1 + + [111402] gdm-2.6.0.8-16 -> [117776] gdm-2.8.0.4-1 + [108333] gedit-2.10.2-3 -> [117719] gedit-2.12.0-1 + [110935] perl-5.8.6-15 -> [117489] perl-5.8.7-0.3.fc5 + + [107237] gok-1.0.3-1 -> [116496] gok-1.0.5-4 + [110356] php-5.0.4-10 -> [118097] php-5.0.5-3 + [110581] gimp-2.2.7-4 -> [116538] gimp-2.2.8-3 + [111654] gnome-applets-2.10.1-9 -> [117721] + gnome-applets-2.12.0-1 + [111691] glibc-2.3.5-10 -> [117966] glibc-2.3.90-12 + [111104] gnome-games-2.10.0-5 -> [117724] + gnome-games-2.12.0-1 + [111214] gnome-media-2.10.2-4 -> [117726] + gnome-media-2.12.0-1 + [106508] kdeadmin-3.4.0-1 -> [118336] kdeadmin-3.4.2-2 + + [110919] gnome-utils-2.10.0-3 -> [117738] + gnome-utils-2.12.0-1 + [110246] gnupg-1.4.1-3 -> [116120] gnupg-1.4.2-3 + [104528] gnuplot-4.0.0-7 -> [117403] gnuplot-4.0.0-8 + [104506] gperf-3.0.1-6 -> [115552] gperf-3.0.1-7 + [104548] grep-2.5.1-48 -> [113236] grep-2.5.1-50 + [108057] xinitrc-4.0.18-1 -> [111974] xinitrc-4.0.19-1 + + [104544] guile-1.6.7-2 -> [117402] guile-1.6.7-4 + [104475] hdparm-5.9-1 -> [112183] hdparm-6.1-1 + [111501] initscripts-8.11.1-1 -> [117977] initscripts-8.14-1 + + [107880] inn-2.4.2-3 -> [115559] inn-2.4.2-4 + [106114] iproute-2.6.11-1 -> [118247] iproute-2.6.14-3 + + [106499] iptables-1.3.0-2 -> [114287] iptables-1.3.2-1 + + [107881] iputils-20020927-22 -> [117698] iputils-20020927-26 + + [111656] isdn4k-utils-3.2-28 -> [115009] isdn4k-utils-3.2-32 + + [105032] joe-3.1-8 -> [112056] joe-3.3-1 + [108237] kdebase-3.4.0-5 -> [118422] kdebase-3.4.2-5 + [106532] kdegames-3.4.0-1 -> [116019] kdegames-3.4.2-1 + + [107198] kdegraphics-3.4.0-2 -> [117508] kdegraphics-3.4.2-3 + + [104526] openobex-1.0.1-3 -> [111937] openobex-1.0.1-4 + + [107226] kdemultimedia-3.4.0-2 -> [115553] + kdemultimedia-3.4.2-1 + [106551] kdeutils-3.4.0-1 -> [117699] kdeutils-3.4.2-2 + + [105322] minicom-2.00.0-21 -> [114175] minicom-2.1-1 + [112015] kernel-2.6.11-1.1369_FC4 -> [118394] + kernel-2.6.13-1.1565_FC5 + [108707] libbtctl-0.4.1-7 -> [114382] libbtctl-0.4.1-8 + + [107067] krb5-1.4-3 -> [118053] krb5-1.4.2-4 + [106252] krbafs-1.2.2-7 -> [115422] krbafs-1.2.2-8 + [111032] kudzu-1.1.116.2-2 -> [118290] kudzu-1.2.7-1 + [105596] lam-7.1.1-3 -> [115564] lam-7.1.1-7.FC5 + [105047] less-382-7 -> [117533] less-382-8 + [104599] libieee1284-0.2.9-2 -> [114409] libieee1284-0.2.9-3 + [...3253 lines suppressed...] - - (x86;x86_64) quanta-devel - - - - (x86;x86_64) raidtools - - - - (x86;x86_64) redhat-java-rpm-scripts - - - - (x86;x86_64) rep-gtk - - - - (x86_64) samba (i386) - - - - (x86;x86_64) sawfish - - - - (x86;x86_64) servletapi - - - - (x86;x86_64) servletapi-devel - - - - (x86;x86_64) shapecfg - - - - (x86;x86_64) struts - - - - (x86;x86_64) struts-webapps - - - - (x86;x86_64) system-config-proc - - - - (x86;x86_64) tomcat - - - - (x86;x86_64) tomcat-devel - - - - (x86;x86_64) tomcat-libs - - - - (x86;x86_64) tomcat-test - - - - (x86;x86_64) unarj - - - - (x86;x86_64) xalan-j - - - - (x86;x86_64) xalan-j-devel - - - - (x86;x86_64) xalan-j-xsltc - - - - (x86;x86_64) xerces-j - - - - (x86;x86_64) xerces-j-devel - - - - (x86;x86_64) xffm-icons - - - - (x86;x86_64) xorg-x11-100dpi-fonts - - - - (x86;x86_64) xorg-x11-75dpi-fonts - - - - (x86;x86_64) xorg-x11-ISO8859-14-100dpi-fonts - - - - (x86;x86_64) xorg-x11-ISO8859-14-75dpi-fonts - - - - (x86;x86_64) xorg-x11-ISO8859-15-100dpi-fonts - - - - (x86;x86_64) xorg-x11-ISO8859-15-75dpi-fonts - - - - (x86;x86_64) xorg-x11-ISO8859-2-100dpi-fonts - - - - (x86;x86_64) xorg-x11-ISO8859-2-75dpi-fonts - - - - (x86;x86_64) xorg-x11-ISO8859-9-100dpi-fonts - - - - (x86;x86_64) xorg-x11-ISO8859-9-75dpi-fonts - - - - (x86;x86_64) xorg-x11-base-fonts - - - - (x86;x86_64) xorg-x11-cyrillic-fonts - - - - (x86;x86_64) xorg-x11-libs-data - - - - (x86;x86_64) xorg-x11-syriac-fonts - - - - (x86;x86_64) xorg-x11-truetype-fonts - - -
-
- Packages Deprecated - - The following packages have been deprecated, and may be removed from - a future release of &DISTRO;: - - - - dbskkd-cdb — Only used by deprecated package - skkinput - - - - FreeWnn — Only used by deprecated package - kinput2-canna-wnn6 - - - - (x86) lilo — GRUB is the - recommended bootloader - - - - miniChinput — IIIMF is the recommended input method - - - - nabi — IIIMF is the recommended input method - - - - ncpfs — No longer part of &DISTRO; profile - - - - skkinput — IIIMF is the recommended input method - - - - xcin — IIIMF is the recommended input method - - -
--->
The following sections contain information regarding packages that @@ -241,35 +241,6 @@ &SERVER-TOOLS; &JAVA-PACKAGE;
-
Core @@ -285,612 +256,21 @@ The Fedora Extras repository is now enabled by default. -
+
&KERNEL; &SECURITY;
- - - &DEVELOPMENT-TOOLS; - -
- Language Support - - This section includes information related to the support of various - languages under &DISTRO;. - -
- The IIIMF Input System - - IIIMF is the Internet/Intranet Input Method Framework. In &FC; - &LOCALVER; the iiimf package is updated to - version 12.2. - - - - File Path Changes - - - The names and locations of some files in the - iiimf packages have changed. - - - The IIIMF server has been renamed from - /usr/sbin/htt to - /usr/bin/iiimd, and the XIM bridge - client renamed from httx to - iiimx. The - init.d script name has not changed: - it is still called iiim. All the - global system configuration files are now located under - /etc/iiim/. - - - Language Engine (LE) developers should note that LE - modules and their data now live under - ${libdir}/iiim/le/<LE_NAME>/, - while runtime data is stored under - /var/lib/iiim/le/<LE_NAME>/. - - - For more information on the exact path and file location - changes, please refer to Fedora IIIMF FAQ: - - - http://www.fedora.redhat.com/projects/i18n/iiimf-faq.html. - - - - - Hotkeys - - - Trigger keys, such as - CtrlSpace - used to activate Input Methods, are now configurable with - the command-line tool iiimf-le-tools. - This feature is only supported by GTK2 applications - currently. For other applications using XIM the trigger - key can be changed using an X resource. Refer to the - IIIMF FAQ at http://www.fedora.redhat.com/projects/i18n/iiimf-faq.html - for more details on how to change trigger hotkeys. - - - Note that the keyname refers to the X key symbol name. For - example, if you want to activate with - Ctrl@, - you need to specify '<Control>at' as the keyname not - '<Control>@'. - - - The per-user configuration of hotkeys does not work - currently with &SEL; in enforcing mode due to lack of - &SEL; policy. In this case, the hotkey can only be - changed in the system-wide configuration. - - - - - Qt Support - - - A Qt immodule for iiimf is now - included. This immodule works but lacks a status window - and is considered experimental. Therefore, the default - for Qt applications is to continue using XIM for IIMF - input. - - - If you wish to try the immodule in a Qt application, first - install the iiimf-qt package, start - the application, then click mouse button-3 in an input - area and select iiimqcf from - the Select Input Method' submenu. - - - - -
-
- + &DEVELOPMENT-TOOLS; + &I18N; &PRINTING; - - - + + &MULTIMEDIA; + &ENTERTAINMENT; &WEB-SERVERS; &SAMBA; &XORG; - + &ENTERTAINMENT;
- + @@ -48,9 +48,9 @@ - + - + ]>
Index: hardware-reqs-en.xml =================================================================== RCS file: /cvs/docs/release-notes/hardware-reqs-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- hardware-reqs-en.xml 25 Oct 2005 02:48:50 -0000 1.1 +++ hardware-reqs-en.xml 25 Oct 2005 09:07:12 -0000 1.2 @@ -230,14 +230,11 @@ &FC; &LOCALVER; - supports only the New World generation of - Apple Power - Macintosh, shipped circa 1999 onwards. It also supports the - 64-bit G5 processor and, POWER processors in IBM - eServer pSeries. - Currently 32-bit IBM - RS/6000 machines are not supported. + supports only the New World generation of Apple + Power Macintosh, shipped circa 1999 onwards. It also supports + the 64-bit G5 processor and, POWER processors in IBM eServer + pSeries. Currently 32-bit IBM RS/6000 machines are not + supported. Index: install-notes-en.xml =================================================================== RCS file: /cvs/docs/release-notes/install-notes-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- install-notes-en.xml 25 Oct 2005 08:34:00 -0000 1.2 +++ install-notes-en.xml 25 Oct 2005 09:07:12 -0000 1.3 @@ -59,88 +59,90 @@ RAM. -
- - The DVD or first CD of the installation set of &FC; is set to be - bootable on supported hardware. In addition, bootable CD images - can be found in the images/ directory of the - DVD or first CD. These will behave differently according to the - hardware: - - - Boot Image Behavior by Hardware + + The DVD or first CD of the installation set of &FC; is set to be + bootable on supported hardware. In addition, bootable CD images + can be found in the images/ directory of + the DVD or first CD. These will behave differently according to + the hardware: + + + Boot Image Behavior by Hardware Apple Macintosh - - The bootloader should automatically boot the appropriate - 32-bit or 64-bit installer. Power management support, - including sleep and backlight level management, is present - in the apmud package, which is in &FEX;. - &FEX; for &FC; is configured by default for yum. Following - installation, apmud can be installed by - running the command yum install apmud - in a terminal. - - - - - 64-bit IBM eServer pSeries (POWER4/POWER5) - - After using OpenFirmware to boot the CD, the bootloader - (yaboot) should automatically boot the - 64-bit installer. - - - - - 32-bit CHRP (IBM RS/6000 and others) - - After using OpenFirmware to boot the CD, select the - linux32 boot image at the - boot: prompt to start the 32-bit installer. - Otherwise, the 64-bit installer is started, which does not - work. - - - - Genesi Pegasos II - - As of &DISTRO; &DISTROVER;, firmware with full support - for ISO9660 file systems is not yet released for the - Pegasos. However, the network boot image can be used. At - the OpenFirmware prompt, enter the command: + + The bootloader should automatically boot the + appropriate 32-bit or 64-bit installer. Power management + support, including sleep and backlight level management, + is present in the apmud package, + which is in &FEX;. &FEX; for &FC; is configured by default + for yum. Following installation, + apmud can be installed by running the + command yum install apmud in a + terminal. + + + + + 64-bit IBM eServer pSeries (POWER4/POWER5) + + After using OpenFirmware to boot the CD, the + bootloader (yaboot) should + automatically boot the 64-bit installer. + + + + + 32-bit CHRP (IBM RS/6000 and others) + + After using OpenFirmware to boot the CD, select the + linux32 boot image at the + boot: prompt to start the 32-bit installer. + Otherwise, the 64-bit installer is started, which does not + work. + + + + Genesi Pegasos II + + As of &DISTRO; &DISTROVER;, firmware with full support + for ISO9660 file systems is not yet released for the + Pegasos. However, the network boot image can be used. At + the OpenFirmware prompt, enter the command: + boot cd: /images/netboot/ppc32.img - - You will also need to configure OpenFirmware on the Pegasos - manually to make the installed &FC; system bootable. To do - this, you need to set the boot-device and - boot-file environment variables - appropriately. - - - - - Network booting - - There are combined images containing the installer - kernel and ramdisk in the images/netboot/ directory of the - install tree. These are intended for network booting with - TFTP, but can be used in many ways. - - - The command yaboot supports tftp - booting for IBM eServer pSeries and Apple Macintosh. - &FED; recommends using yaboot over the netboot images. - + + You will also need to configure OpenFirmware on the + Pegasos manually to make the installed &FC; system + bootable. To do this, you need to set the + boot-device and boot-file + environment variables appropriately. + + + + + Network booting + + There are combined images containing the installer + kernel and ramdisk in the images/netboot/ directory of the + install tree. These are intended for network booting with + TFTP, but can be used in many ways. + + + The command yaboot supports tftp + booting for IBM eServer pSeries and Apple Macintosh. &FED; + recommends using yaboot over the netboot images. + - - + + +
Anaconda Notes - + Index: multimedia-en.xml =================================================================== RCS file: /cvs/docs/release-notes/multimedia-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- multimedia-en.xml 25 Oct 2005 08:34:00 -0000 1.2 +++ multimedia-en.xml 25 Oct 2005 09:07:12 -0000 1.3 @@ -59,7 +59,7 @@ playback or recording, because the MP3 and MPEG (DVD) formats are patented, and the patent owners have not provided the necessary licenses. For more information, refer to . + linkend="sn-multimedia-excluded"/>. Index: overview-en.xml =================================================================== RCS file: /cvs/docs/release-notes/overview-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- overview-en.xml 25 Oct 2005 02:48:50 -0000 1.1 +++ overview-en.xml 25 Oct 2005 09:07:12 -0000 1.2 @@ -1,5 +1,13 @@
Overview of This Release + + Information Out-of-Date + + The content in this section needs to be updated for &DISTRO; + &DISTROVER; + + + - &SEL; — This release includes coverage for 80 new daemons by the targeted policy. There are changes to the @@ -543,42 +547,6 @@ -
— Technical release notes From fedora-docs-commits at redhat.com Tue Oct 25 19:40:58 2005 From: fedora-docs-commits at redhat.com (Karsten Wade (kwade)) Date: Tue, 25 Oct 2005 15:40:58 -0400 Subject: release-notes package-movement-en.xml, 1.3, 1.4 package-notes-en.xml, 1.3, 1.4 Message-ID: <200510251940.j9PJewAw010132@cvs-int.fedora.redhat.com> Author: kwade Update of /cvs/docs/release-notes In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv10111 Modified Files: package-movement-en.xml package-notes-en.xml Log Message: Typos that broke the build, sorry, forgot to test the build before I did my last commits. Index: package-movement-en.xml =================================================================== RCS file: /cvs/docs/release-notes/package-movement-en.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- package-movement-en.xml 25 Oct 2005 09:07:12 -0000 1.3 +++ package-movement-en.xml 25 Oct 2005 19:40:56 -0000 1.4 @@ -1052,7 +1052,6 @@ Screensavers not installed by default anymore? Explain why and provide commands to install them. - ) - -Advanced RPM Packaging - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Chapter - - - - *Defining package dependency information - - - - *Setting triggers - - - - *Writing verification scripts - - - - *Creating subpackages - - - - *Creating relocatable packages - + + + Advanced RPM Packaging - *Defining conditional builds + This chapter covers: - + + + + Defining package dependency information + + + + + Setting triggers + + + + + Writing verification scripts + + + + + Creating subpackages + + + + + Creating relocatable packages + + + + + Defining conditional builds + + + The previous chapter introduced the RPM spec file, which controls how RPM packages are built and installed. This chapter delves into @@ -46,7 +44,6 @@ making relocatable packages, starting with how to specify package dependencies. - Defining Package Dependencies @@ -416,7 +413,6 @@ - Setting Triggers @@ -859,7 +855,6 @@ chmod 0400 /var/ftp/bin/bin.md5 - Writing Verification Scripts @@ -906,7 +901,6 @@ See Chapter 5 for more on package verification. - Creating Subpackages @@ -1198,7 +1192,6 @@ - Creating Relocatable Packages @@ -1341,7 +1334,6 @@ - Defining Conditional Builds @@ -1653,7 +1645,6 @@ - Summary @@ -1721,6 +1712,7 @@ + - -RPM Command Reference - - - In This Appendix - - - - *rpm command - + + + RPM Command Reference - *rpmbuild command + This appendix covers: - + + + + rpm command + + + + + rpmbuild command + + + This appendix covers the syntax of the command-line options for the rpm and rpmbuild commands. - The rpm Command @@ -1704,7 +1706,6 @@ - The rpmbuild Command @@ -2307,6 +2308,7 @@ + - Index: rpm-guide-creating-rpms-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-creating-rpms-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- rpm-guide-creating-rpms-en.xml 4 Oct 2005 01:48:20 -0000 1.1 +++ rpm-guide-creating-rpms-en.xml 26 Oct 2005 01:54:11 -0000 1.2 @@ -1,44 +1,42 @@ - - -Creating RPMs: An Overview - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Chapter - - - - *Preparing to build RPMs - - - - *Planning for RPMs - - - - *Explaining the build process - - - - *Using build files - - - - *Seeing the results - + + + Creating RPMs: An Overview - *Verifying your RPMs + This chapter covers: - + + + + Preparing to build RPMs + + + + + Planning for RPMs + + + + + Explaining the build process + + + + + Using build files + + + + + Seeing the results + + + + + Verifying your RPMs + + + Thus far in this book, all the commands presented have been used to manage or query packages. With this chapter, though, you start @@ -47,7 +45,6 @@ use, if only for the ease of management that the RPM system provides. - Creating RPMs allows you to create a consistent set of applications for use on all systems in your organization and easily manage those @@ -56,7 +53,6 @@ customize for your environment. Making RPMs of the customized applications reduces work and makes the customizations consistent. - This chapter introduces the RPM system from the point of view of creating RPMs and demonstrates the steps and planning necessary to @@ -64,7 +60,6 @@ RPM-building topics covered in depth in the remaining chapters in this part. - Preparing to Build RPMs @@ -600,7 +595,6 @@ - Building RPMs @@ -1555,7 +1549,6 @@ - Verifying Your RPMS @@ -1647,7 +1640,6 @@ for more on the -V option. - Summary @@ -1674,6 +1666,7 @@ + - -Customizing RPM Behavior - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Chapter - - - - *Defining RPM macros - - - - *Configuring RPM settings - + + + Customizing RPM Behavior - *Adding popt aliases + This chapter covers: - + + + + Defining RPM macros + + + + + Configuring RPM settings + + + + + Adding popt aliases + + + RPM provides a high degree of customization in the form of basic settings, such as where your RPM database is located and the path to @@ -35,7 +30,6 @@ ways to customize RPM behavior: RPM macros, RPM rc settings, and popt aliases. - Customizing with RPM Macros @@ -345,7 +339,6 @@ - Configuring RPM Settings @@ -733,7 +726,6 @@ - Adding Popt Aliases @@ -949,7 +941,6 @@ - Summary @@ -967,6 +958,7 @@ + - Index: rpm-guide-dependencies-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-dependencies-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- rpm-guide-dependencies-en.xml 4 Oct 2005 01:49:40 -0000 1.1 +++ rpm-guide-dependencies-en.xml 26 Oct 2005 01:54:11 -0000 1.2 @@ -1,42 +1,46 @@ - - -Package Dependencies - - - In This Chapter - - - - *Understanding dependencies - - - - *Package capabilities - - - - *Version dependencies - - - - *Checking dependencies - + + + Package Dependencies - *Triggers + This chapter covers: - + + + + Understanding dependencies + + + + + Package capabilities + + + + + Version dependencies + + + + + Checking dependencies + + + + + Triggers + + + Packages aren???t built in a vacuum. Web applications, for example, build on system networking libraries, system-encryption libraries, and system-file input and output libraries. - This chapter covers dependencies between packages, along with ways to discover and manage those dependencies. - Understanding the Dependency Concept @@ -281,7 +285,6 @@ - Checking for Dependencies @@ -1170,7 +1173,6 @@ - Triggers @@ -1532,7 +1534,6 @@ package changes. - Summary @@ -1570,6 +1571,7 @@ + - Index: rpm-guide-development-tools-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-development-tools-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- rpm-guide-development-tools-en.xml 4 Oct 2005 01:50:09 -0000 1.1 +++ rpm-guide-development-tools-en.xml 26 Oct 2005 01:54:11 -0000 1.2 @@ -1,32 +1,27 @@ - - -Linux Text Editors and Development Tools - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Appendix - - - - *General text editors - - - - *C-specific tools and integrated development environments - + + + Linux Text Editors and Development Tools - *Python-specific development tools + This appendix covers: - + + + + General text editors + + + + + C-specific tools and integrated development environments + + + + + Python-specific development tools + + + Linux includes a number of text editors and integrated development environments (IDEs), going from plain old text editors all the way @@ -36,7 +31,6 @@ configuration data, so Linux has always included a number of text editors. - This appendix lists a number of tools for those who have not yet set up an RPM development environment on Linux. Note that choosing an @@ -46,12 +40,10 @@ out what you have installed on your system and see if that works for you. - Note that Internet sites may change or disappear, so you may have to search to find these tools. - General Text Editors @@ -84,7 +76,6 @@ Replace gedit with the editor you choose. - Programming Text Editors @@ -115,7 +106,6 @@ www.ibm.com/java/jdk/ and select the IBM Developer Kit for Linux. - Integrated Development Environments for C Programming @@ -148,7 +138,6 @@ www.eclipse.org/tools/downloads.html. - Integrated Development Environments for Python Programming @@ -205,6 +194,7 @@ + - -Supplemental Packaging Software - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Chapter - - - - *Understanding packaging aids - + + + Supplemental Packaging Software - *Manipulating packages + This chapter covers: - + + + + Understanding packaging aids + + + + + Manipulating packages + + + RPM is intended to make system management easier, both for system administrators and other users who do all the day-to-day work of @@ -39,7 +33,6 @@ have less work ahead of them, since they need only concern themselves with the first step. - After a packager has prepared an RPM package once, RPM makes the first step (compilation and configuration) easier when the packager @@ -56,7 +49,6 @@ same application, but once created, the RPM package takes less time and effort to keep current than the gzipped tarball requires. - Packaging Aids @@ -1452,7 +1444,6 @@ - Summary @@ -1489,6 +1480,7 @@ + - -Licensing RPM - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - + + + Licensing RPM When incorporating someone else's existing code into your software project, you should always examine the license of the code @@ -20,7 +11,6 @@ This is true for commercial code and commercial projects, and it is equally true for freely licensed code and free software projects. - RPM itself and most discussed helper applications (rpmlint, rpm-spec-mode, and so forth) are free software, meaning that the @@ -28,7 +18,6 @@ these tools are considered open source software, which means the source code for the applications are also available. - These facts do not mean that they are unlicensed software, or that their source code can be used in any desired fashion. RPM and these @@ -46,9 +35,7 @@ GPL on your project, should you decide to use GPL'ed code in any commercially licensed project you might undertake). - - The GNU General Public License @@ -490,6 +477,7 @@ + - -RPM Management Software - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Chapter - - - - *Finding packages in RPM format - - - - *Graphical tools to manage RPM packages - + + + RPM Management Software - *Extending RPM management with additional tools + This chapter covers: - + + + + Finding packages in RPM format + + + + + Graphical tools to manage RPM packages + + + + + Extending RPM management with additional tools + + + You can find a variety of software packages to ease the work of managing RPM-based systems. These utilities can help you find a @@ -38,12 +33,10 @@ with more recent versions or simplification of software installation by automating installation of any required software dependencies. - This chapter covers a number of tools for finding packages in RPM format, as well as tools to help manage the RPMs on your system. - Locating RPMs @@ -670,7 +663,6 @@ - Graphical RPM Management @@ -965,7 +957,6 @@ - Extending RPM Management @@ -2074,7 +2065,6 @@ - Summary @@ -2118,6 +2108,7 @@ + - Index: rpm-guide-online-resources-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-online-resources-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- rpm-guide-online-resources-en.xml 4 Oct 2005 01:54:38 -0000 1.1 +++ rpm-guide-online-resources-en.xml 26 Oct 2005 01:54:11 -0000 1.2 @@ -1,33 +1,26 @@ - - -RPM Resources - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Appendix - - - - *Finding RPM sites on the Internet - + + + RPM Resources - *Accessing RPM newsgroups and mailing lists + This appendix covers: - + + + + Finding RPM sites on the Internet + + + + + Accessing RPM newsgroups and mailing lists + + + This appendix covers the material available on the Internet for working with RPM. - Finding RPM Sites @@ -590,7 +583,6 @@ - Accessing RPM Mailing Lists and Newsgroups @@ -613,6 +605,7 @@ + - -Using RPM on Non-Red Hat Linuxe - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Chapter - - - - *Dealing with RPM issues on other versions of Linux - - - - *RPM standardization - - - - *Working around RPM differences when installing RPMs - - - - *Working around RPM differences when building RPMs - + + + Using RPM on Non-Red Hat Linuxes - *Dealing with non-RPM-based Linux distributions + This chapter covers: - + + + + Dealing with RPM issues on other versions of Linux + + + + + RPM standardization + + + + + Working around RPM differences when installing RPMs + + + + + Working around RPM differences when building RPMs + + + + + Dealing with non-RPM-based Linux distributions + + + Although its name was originally the Red Hat Package Manager, RPM has been adopted by most major Linux distributions. With this adoption, RPM has moved from its Red Hat roots, and RPM now stands for the RPM Package Manager. - In addition, the RPM package format is being adopted by the Linux Standards Base (LSB). The LSB defines a set of standards to help maintain compatibility for all Linux distributions. - Cross Reference - See www.linuxbase.org for more on the LSB. - This chapter covers differences in how Linux distributions use RPM, ways to work around these differences, and also tools you can use for non-RPM distributions. - Troubleshooting RPM Installation Issues @@ -307,7 +299,6 @@ - Handling Problems Building RPMs @@ -787,7 +778,6 @@ - Dealing with Non-RPM-Based Linux Versions @@ -816,7 +806,6 @@ - Standardizing RPMs @@ -870,7 +859,6 @@ - Summary @@ -903,6 +891,7 @@ + - -RPM on Other Operating Systems - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Chapter - - - - *Running RPM on other operating systems - - - - *Bootstrapping RPM on other operating systems - - - - *Setting up the RPM environment - - - - *Creating non-Linux RPMs - - - - *Setting up an RPM build environment - + + + RPM on Other Operating Systems - *Cross-building packages + This chapter covers: - + + + + Running RPM on other operating systems + + + + + Bootstrapping RPM on other operating systems + + + + + Setting up the RPM environment + + + + + Creating non-Linux RPMs + + + + + Setting up an RPM build environment + + + + + Cross-building packages + + + RPM was originally designed on Linux and for most of its life has been a Linux-centric package management system. But most Linux @@ -46,26 +44,22 @@ operating systems. Linux is, after all, a Unix-workalike operating system. - The RPM system is no exception. It has been ported to a number of operating systems, including quite a few Unix variants. The source code is freely available, so you can port RPM to other systems as well. - This chapter covers running RPM on non-Linux operating systems, including getting the RPM system in the first place, bootstrapping an RPM environment, and creating packages for other operating systems. - The first step is to get RPM for your system, or port RPM if it isn???t already available. - Running RPM on Other Operating Systems @@ -454,7 +448,6 @@ - Bootstrapping RPM On Other Operating Systems @@ -887,7 +880,6 @@ - Setting Up the RPM System @@ -1359,7 +1351,6 @@ - Creating Non-Linux RPMS @@ -1566,7 +1557,6 @@ - Summary @@ -1616,6 +1606,7 @@ + - -RPM Package File Structure - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Appendix - - - - *RPM package file structure - - - - *RPM header entry formats - + + + RPM Package File Structure - *Payload format + This appendix covers: - + + + + RPM package file structure + + + + + RPM header entry formats + + + + + Payload format + + + This appendix describes the format of RPM package files. You can combine this information with C, Perl, or Python data structures to @@ -35,30 +30,24 @@ attempt to access the files directly, as you may inadvertently damage the RPM file. - Cross Reference - Chapters 16, 17, and 18 cover programming with C, Python, and Perl, respectively. - The RPM package format described here has been standardized as part of the Linux Standards Base, or LSB, version 1.3. - Cross Reference - The LSB 1.3 section on package file formats is available at www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB.html#PACKAGEFMT. - The Package File @@ -2565,6 +2554,7 @@ + - -Packaging Guidelines - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Chapter - - - - *Avoiding common mistakes - + + + Packaging Guidelines - *Following good practices + This chapter covers: - + + + + Avoiding common mistakes + + + + + Following good practices + + + RPM is a complex system that helps manage thousands of packages for a complex operating system. Furthermore, RPM is very, very flexible. @@ -31,12 +25,10 @@ problems with your RPMs. Following some best practices guidelines will help you avoid future problems as you release RPM updates. - This chapter covers ways to avoid common problems as well as best-practice guidelines for creating your own RPMs. - Avoiding Common Problems @@ -282,7 +274,6 @@ - Following Good Practices @@ -652,7 +643,6 @@ - Summary @@ -685,6 +675,7 @@ + - -Programming RPM with C - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Chapter - - - - *Using the RPM C library - - - - *Setting up a development environment - - - - *Programming with the RPM C library - - - - *The power of popt for command-line argument processing - + + + Programming RPM with C - *Comparing package files to installed packages + This chapter covers: - + + + + Using the RPM C library + + + + + Setting up a development environment + + + + + Programming with the RPM C library + + + + + The power of popt for command-line argument + processing + + + + + Comparing package files to installed packages + + + The RPM C library allows you to perform all the operations of the rpm command from within your own C or C++ programs. - The reason is simple: The rpm command was created using the RPM libraries. These same libraries are available for you to use in your own programs. - The rpm command itself is quick and, for the most part, simple. So, why would you want to write RPM programs? - There are many reasons, some of which are listed here: - *Speed: If you need to perform a task on many RPM files such as verifying a large set of files, then performing the task from one program will be a lot faster than launching the rpm command for each file. - *Custom options: If you need to do something the rpm command doesn't offer, or doesn't make easy, then you may want to write your own program. - *Convenience: If you need to make many packages quickly, with custom options, your best bet may be to create a program suited for your @@ -76,7 +68,6 @@ writing RPM shell scripts goes much faster than writing whole programs. - *Installation programs: The Windows world has standardized on graphical installation programs such as InstallShield or @@ -85,12 +76,10 @@ best of both worlds by writing a graphical installation program on top of the RPM system. - *Integration with environments: You may want to better integrate RPM with a Linux desktop environment such as GNOME or KDE. - *Working with other languages: This book covers programming RPM with C, the core language for the library, as well as the Python and Perl @@ -98,7 +87,6 @@ bind with other languages such as Tcl, Ruby, or even C# (especially one of the C# implementations for Linux). - This chapter and the next cover RPM programming. This chapter covers the RPM C programming library, which provides low-level access to @@ -108,7 +96,6 @@ your best bet is to try the Python API first. Even so, there is a lot you can do with the RPM C library. - Programming with the C Library @@ -968,7 +955,6 @@ - The Power of popt @@ -2265,7 +2251,6 @@ - Working with RPM Files @@ -2744,7 +2729,6 @@ - Programming with the RPM Database @@ -3083,7 +3067,6 @@ - Comparing an RPM File to an Installed Package @@ -3913,7 +3896,6 @@ jikes Fri 25 Oct 2002 06:49:38 PM CDT - Where to Go from Here @@ -3947,7 +3929,6 @@ organization can help you locate the functions you need. - Summary @@ -3981,6 +3962,7 @@ + - Index: rpm-guide-programming-perl-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-programming-perl-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- rpm-guide-programming-perl-en.xml 4 Oct 2005 01:58:18 -0000 1.1 +++ rpm-guide-programming-perl-en.xml 26 Oct 2005 01:54:11 -0000 1.2 @@ -1,37 +1,33 @@ - - -Programming RPM with Perl - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Chapter - - - - *Using the RPM2 module to access information on package files - - - - *Querying the RPM database from Perl - - - - *Cross-referencing capabilities by the packages that provide and - require capabilities - + + + Programming RPM with Perl - *Extracting information on packages + This chapter covers: - + + + + Using the RPM2 module to access information on package files + + + + + Querying the RPM database from Perl + + + + + Cross-referencing capabilities by the packages that provide and + require capabilities + + + + + Extracting information on packages + + + Perl is one of the most popular scripting languages. Used by system administrators, software developers, and a host of other users, Perl @@ -39,24 +35,20 @@ Perl stands for Practical Extraction and Report Language, or sometimes Pathologically Eclectic Rubbish Lister. - Note - In the same vein, LISP stands for Lots of Irritating Single Parenthesis and COBOL for Completely Obnoxious Business Oriented Language. - I began my book Cross-Platform Perl (John Wiley & Sons, 2000) by mentioning that when I first started learning Perl, I thought it was an evil plot. I still do. But it is a very practical evil plot. You can get a lot of work done with Perl, and quickly. - Because of a long history of text processing, Perl is especially popular among system administrators. Perl also supports add-on @@ -66,30 +58,24 @@ like the Perl syntax script with Perl anyway, because the available modules save a lot of time. - Cross Reference - See search.cpan.org, the Comprehensive Perl Archive Network, for a listing of many Perl modules. - This chapter covers working with RPM files and the RPM database using Perl. You can combine RPM usage with other Perl usage, such as generating HTML files or downloading RPMs over a network link. - Cross Reference - Many of the RPM tools covered in Chapter 8 are written in Perl. - Getting and Using the Perl RPM Modules @@ -127,7 +113,6 @@ objects: RPM files and installed packages. - Working with RPM Files @@ -355,7 +340,6 @@ - Programming with the RPM Database @@ -1489,7 +1473,6 @@ - Where to Go from Here @@ -1550,7 +1533,6 @@ You can download all these modules from the CPAN site. - Summary @@ -1580,6 +1562,7 @@ + - -Programming RPM with Python - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Chapter - - - - *Using the RPM with Python - - - - *Installing the necessary modules - - - - *Programming with the RPM database - - - - *Programming with RPM files - + + + Programming RPM with Python - *Installing packages programmatically + This chapter covers: - + + + + Using the RPM with Python + + + + + Installing the necessary modules + + + + + Programming with the RPM database + + + + + Programming with RPM files + + + + + Installing packages programmatically + + + Setting Up a Python Development Environment @@ -123,7 +120,6 @@ - The Python API Hierarchy @@ -251,7 +247,6 @@ version. - Programming with the RPM Database @@ -1321,7 +1316,6 @@ - Reading Package Files @@ -1623,7 +1617,6 @@ - Dependency Comparisons @@ -1759,7 +1752,6 @@ a package isn't installed. - Installing and Upgrading Packages @@ -3009,7 +3001,6 @@ - Where to Go from Here @@ -3047,7 +3038,6 @@ the Vaults of Parnassus listing of tutorials. - Summary @@ -3077,6 +3067,7 @@ + - Index: rpm-guide-rpm-evolution-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-rpm-evolution-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- rpm-guide-rpm-evolution-en.xml 4 Oct 2005 02:00:07 -0000 1.1 +++ rpm-guide-rpm-evolution-en.xml 26 Oct 2005 01:54:11 -0000 1.2 @@ -1,16 +1,7 @@ - - -RPM Feature Evolution - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - + + + RPM Feature Evolution Although RPM implementations are largely compatible from version to version, RPM packagers must remember that RPM is a still-evolving @@ -25,13 +16,11 @@ considering these revisions of RPM, the main releases of interest are RPM 2.5, RPM 3.0.5, RPM 4.0.4, and RPM 4.1. - RPM 2.5 is not widely used anymore; packages should target RPM 2.5 only if the intention is for the RPM package to install using absolutely all RPM versions. - RPM 3.0.5 is the final release of the 3.x series of RPM. It was the release of RPM shipped with Red Hat Linux 6.2 and older releases. It @@ -39,7 +28,6 @@ distributions use an RPM implementation version based on RPM 3.0.5, for example. (Red Hat Linux was upgraded to RPM 4 via an errata.) - RPM 4.0.4 was used with the 7.x releases of Red Hat Linux, and RPM 4.1 first shipped with Red Hat Linux 8.0. Packages produced @@ -47,7 +35,6 @@ RPM still in use today. Packages produced targeting RPM 4.0.4 or RPM 4.1 will work only with recent RPM implementations. - RPM 2.5 is the oldest version of RPM that can, by any stretch of the imagination, still be considered in use. With RPM 2.5, most of the @@ -57,48 +44,40 @@ also the first version of RPM to use the RPM version 3 RPM file format. - RPM 2.5.3 added support for Epochs to the RPM header, implementing RPMTAG_EPOCH. - RPM 2.5.4 introduced the %license and %readme file types, which can be used in the RPM spec file to indicate license and README files. - RPM 2.5.6 added support for usage of the Epoch: keyword in the RPM spec file, allowing you to force an Epoch for your package. The Epoch: keyword replaced the older Serial: keyword, which semantically behaved similarly. - RPM 2.5.7 enforced the previously implied standard that the "-" character should not be used within the Version or Release fields in the RPM spec file. - RPM 2.90 introduced support for signing and verifying RPM package files using GPG, the GNU Privacy Guard. - RPM 2.91 allowed the usage of Provides: directives that defined absolute paths to provided files. Prior to RPM 2.91, Provides: could be used only for listing provided capabilities, not for using statements like Provides: /path/to/file to indicate provided files. - RPM 3.0.2 permitted usage of multiple Provides: lines for the first time, eliminating the need to combine all provided capabilities and files on the same line in the spec file. - RPM 3.0.3 added support for versioned dependencies. Prior to RPM 3.0.3, spec files could indicate that a package required another @@ -106,30 +85,24 @@ indicate the acceptable versions of the required package or which version of the capability the package provided. - RPM 3.0.4 introduced CompressedFileNames support to RPM. Prior to RPM 3.0.4, RPM packaged the absolute paths of all archived files within the package file. Package file headers contained statements such as - fileName #0: /usr/bin/ar - fileName #1: /usr/bin/as - fileName #2: /usr/bin/gasp - fileName #3: /usr/bin/gprof - With CompressedFileNames support, the RPM package file header instead stores the directory name, then just the base name of files @@ -137,31 +110,24 @@ such as the following for a given directory with a number of files within that directory: - dirName #0: /usr/bin - baseName dirIndex - #0 ar 0 - #1 as 0 - #2 gasp 0 - #3 gprof 0 - Each file entry now holds the file's base name within the directory, as well as an index number that refers to the directory entry. Since @@ -169,7 +135,6 @@ CompressedFileNames support results in significant memory savings when processing packages for installation. - RPM 3.0.5 added PayloadIsBzip2 support to RPM, allowing the data payload of RPM package files to be compressed using bzip2 instead of @@ -181,7 +146,6 @@ version 4 file format packages; packages produced with RPM 3.0.5 can only be RPM version 3 file format, however. - RPM 4.0 implemented several significant changes to RPM. RPM 4.0 created package files using RPM version 4 package file format. RPM @@ -211,12 +175,10 @@ removing the need to provide self-capabilities within the package spec file. - RPM 4.0.2 introduced the use of SHA-1 message digests to validate RPM header regions. - RPM 4.0.3 added the %dev(type,major,minor) spec file directive, allowing creation of device nodes. In addition, the %configure spec @@ -227,7 +189,6 @@ files in RPM version 3 package file format by default, although it still supports RPM version 4 package file format as well. - RPM 4.0.4 provided PartialHardlinkSets support. RPM package files are sometimes created which contain multiple copies of the same @@ -246,12 +207,10 @@ determined dependencies. In addition, RPM 4.0.4 provides transaction support for RPM. - RPM 4.1 adds separate header DSA and RSA signatures, allowing verification of RPM package headers. - Finally, when considering the RPM features required by your prepared package, remember that some required RPM features are specified Index: rpm-guide-rpm-overview-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-rpm-overview-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- rpm-guide-rpm-overview-en.xml 4 Oct 2005 02:00:40 -0000 1.1 +++ rpm-guide-rpm-overview-en.xml 26 Oct 2005 01:54:11 -0000 1.2 @@ -1,45 +1,38 @@ - - -RPM Overview - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Chapter - - - - *Understanding the package file - - - - *Querying the RPM database - + + + RPM Overview - *Running RPM commands + This chapter covers: - + + + + Understanding the package file + + + + + Querying the RPM database + + + + + Running RPM commands + + + Working with RPM packages, files, commands, and databases can be complicated. There are thousands of files, for hundreds if not thousands of packages, installed on your system. You need some way to manage it all. The RPM system can help you do that. - This chapter provides an overview of the components that make up the RPM system for package management: package files, databases, and RPM commands. - Understanding the Package File @@ -235,7 +228,6 @@ - Querying the RPM Database @@ -335,7 +327,6 @@ 5. - Running RPM Commands @@ -701,7 +692,6 @@ - Summary @@ -717,6 +707,7 @@ + - -Controlling the Build with rpmbuild - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Chapter - - - - *Building with the rpmbuild command - - - - *Building RPMs without an external spec file - - - - *Working with source RPMs - - - - *Optimizing builds - + + + Controlling the Build with <command>rpmbuild</command> - *Signing built RPMs + This chapter covers: - + + + + Building with the rpmbuild command + + + + + Building RPMs without an external spec file + + + + + Working with source RPMs + + + + + Optimizing builds + + + + + Signing built RPMs + + + The preceding chapters in this Part cover details on how to put together RPMs. This chapter rounds out the discussion by delving into more details on the rpmbuild command. - You can customize how rpmbuild creates RPMs, and you can use RPM commands to test and debug your package. - Building RPMs with the rpmbuild Command @@ -526,7 +521,6 @@ - Building RPMs Without an External Spec File @@ -718,7 +712,6 @@ - Working with Source RPMs @@ -1095,7 +1088,6 @@ - Signing Built RPMs @@ -1750,7 +1742,6 @@ - Summary @@ -1785,6 +1776,7 @@ + - -Automating RPM with Scripts - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Chapter - - - - *Deciding when to program and when to script - - - - *Examining RPM files with scripts - + + + Automating RPM with Scripts - *Querying the RPM database with scripts + This chapter covers: - + + + + Deciding when to program and when to script + + + + + Examining RPM files with scripts + + + + + Querying the RPM database with scripts + + + The rpm command provides a very high-level view of package management. Most of the operations you need to perform require only @@ -34,12 +29,10 @@ command tend to get very complex, however, especially for detailed queries. That???s where scripting can help. - This chapter covers scripting, specifically shell scripting, with the rpm command, especially for newcomers to Linux scripting - Scripting @@ -94,7 +87,6 @@ Don???t get caught up in this. Use the right tool for the job. - Distinguishing Scripting Languages from Programming Languages @@ -191,7 +183,6 @@ - Deciding When to Program and When to Script @@ -238,7 +229,6 @@ and Chapter 18 covers Perl scripting. - Shell Scripting Basics @@ -857,7 +847,6 @@ - Examining RPM Files @@ -1005,7 +994,6 @@ install. - Querying the RPM Database @@ -1119,7 +1107,6 @@ - Where to Go From Here @@ -1152,7 +1139,6 @@ perform. - Summary @@ -1178,6 +1164,7 @@ + - -Spec File Syntax - - - In This Appendix - - - - *The package information tags - + + + Spec File Syntax - *Build sections + This appendix covers: - + + + + The package information tags + + + + + Build sections + + + The RPM spec file is divided into two main parts: the package information tags, such as the name of the package, and the build sections, such as the commands to compile the software. - The following sections summarize the spec file syntax. - Package Information Tags @@ -297,7 +298,6 @@ - Macros @@ -658,7 +658,6 @@ - Build Sections @@ -776,7 +775,6 @@ - File Tags @@ -848,7 +846,6 @@ - The Change Log @@ -873,6 +870,7 @@ + - Index: rpm-guide-specfiles-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-specfiles-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- rpm-guide-specfiles-en.xml 4 Oct 2005 02:15:56 -0000 1.1 +++ rpm-guide-specfiles-en.xml 26 Oct 2005 01:54:11 -0000 1.2 @@ -1,40 +1,37 @@ - - -Working with Spec Files - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Chapter - - - - *Writing spec files - - - - *Defining package information - - - - *Controlling the build - - - - *Listing the files in the package - + + + Working with Spec Files - *Defining spec file macros + This chapter covers: - + + + + Writing spec files + + + + + Defining package information + + + + + Controlling the build + + + + + Listing the files in the package + + + + + Defining spec file macros + + + The previous chapter introduces the concepts of how to build RPMs, and briefly covered the spec file, which controls how RPM packages @@ -42,13 +39,11 @@ files and the next chapter covers advanced spec file topics such as using conditional commands and making relocatable packages. - A spec file defines all the commands and values that are required for creating a package, everything from the name and version number to the actual commands used to build the program you are packaging. - This chapter covers the spec file syntax and how to write spec files. In goes in depth into defining information about your @@ -56,7 +51,6 @@ exactly should go into the package, and customizing your build with RPM macros. - Reading Spec Files @@ -104,7 +98,6 @@ these sections. - Writing Spec Files @@ -311,7 +304,6 @@ - Defining Package Information @@ -840,7 +832,6 @@ - Controlling the Build @@ -1522,7 +1513,6 @@ - Filling the List of Files @@ -2134,7 +2124,6 @@ - Adding Change Log Entries @@ -2162,7 +2151,6 @@ - updated to 1.3 - Defining Spec File Macros @@ -2670,7 +2658,6 @@ - Creating XML Spec Files @@ -2866,7 +2853,6 @@ format will likely change. - Summary @@ -2916,6 +2902,7 @@ + - -Transactions - - - In This Chapter - - - - *Understanding transactions - - - - *Querying for packages based on transactions - - - - *Rolling back transactions - + + + Transactions - *Saving old packages when upgrading + This chapter covers: - + + + + Understanding transactions + + + + + Querying for packages based on transactions + + + + + Rolling back transactions + + + + + Saving old packages when upgrading + + + When packages depend on other packages, you may have to install multiple packages to add a single application. Some of the packages @@ -30,7 +35,6 @@ RPM system understood this problem and added the concept of transactions to RPM. - This chapter covers transactions and how they can help you cleanly install a set of dependent packages. But transactions won???t solve @@ -38,7 +42,6 @@ dependencies by using the techniques provided in the last three chapters. - Understanding Transactions @@ -117,7 +120,6 @@ - Transactions with the rpm Command @@ -510,7 +512,6 @@ - Saving Old Packages @@ -634,7 +635,6 @@ Download rpmrebuild from http://rpmrebuild.sourceforge.net/. - Summary @@ -672,6 +672,7 @@ + - -Using the RPM Database - - - In This Chapter - - - - *Querying the RPM database - - - - *Getting information on RPM files - - - - * Finding out which packages own files on your system - - - - * Verifying installed packages - - - - *Backing up the RPM database - + + + Using the RPM Database - *Repairing damaged RPM databases + This chapter covers: - + + + + Querying the RPM database + + + + + Getting information on RPM files + + + + + Finding out which packages own files on your system + + + + + Verifying installed packages + + + + + Backing up the RPM database + + + + + Repairing damaged RPM databases + + + Every package you install with RPM is recorded in the RPM database. The RPM system includes commands to query this database to find out which packages are installed and to provide quite a few details about these packages. - This chapter covers querying both the RPM database and RPM package files. Both types of query are important: - *Query the RPM database to see what is installed, or not installed, on your system. - *Query package files to see what the files require, as well as what the files provide. - In addition to querying the RPM database, you can use the database to verify packages. Since this database is so important to the management of your Linux system, this chapter covers how to back it up, as well as how to repair a damaged RPM database. - Querying the RPM Database @@ -713,7 +715,6 @@ - Getting Information on Packages @@ -3617,7 +3618,6 @@ - Getting Information on Package Files @@ -3767,7 +3767,6 @@ - Verifying Installed RPM Packages @@ -4220,7 +4219,6 @@ - Working With the RPM Database @@ -4480,7 +4478,6 @@ - Summary @@ -4501,6 +4498,7 @@ + - -Using RPM - - - Copyright (c) 2005 by Eric Foster-Johnson. This material may be - distributed only subject to the terms and conditions set forth in - the Open Publication License, v1.0 or later (the latest version is - presently available at http://www.opencontent.org/openpub/). - - - - - - In This Chapter - - - - *Installing and upgrading software - + + + Using RPM - *Removing software + This chapter covers: - + + + + Installing and upgrading software + + + + + Removing software + + + This chapter covers the most common uses for RPM: installing, removing, and upgrading software. These are the most frequently used RPM commands. - The RPM system includes the options you might expect, such as installing a package, but there???s a lot more you can do. For @@ -37,7 +30,6 @@ rpm options you can use to get information and feedback on installation, for example. - The rpm Command @@ -50,7 +42,6 @@ reading this chapter. - Upgrading and Installing Software @@ -1737,7 +1728,6 @@ - Removing Software @@ -1925,7 +1915,6 @@ - Other rpm Command Options @@ -2037,7 +2026,6 @@ --pipe command_to_send_out_to - Summary @@ -2148,6 +2136,7 @@ + --- NEW FILE desktop-zh_CN.xml ---
?????? ?????? GNOME 2.12 ??? KDE 3.4.2 ??????????????? ?????????????????????????????? GNOME 2.12.1???????????????????????????????????? GNOME 2.14 ????????????????????? gnome-power-manager????????????????????? (HAL) ???????????????????????? UPS ????????????????????? -- ????????????????????????????????????????????? (????????????????????????????????????????????????????????????)??? gnome-screensaver????????????????????????????????????????????? ???????????? ????????? fontconfig ??? shared-mime-info ????????????????????? (????????????????????????????????????????????????????????????)?????????????????????????????????????????? ??????????????????????????????????????????????????????????????? GNOME 2.12 ?????????????????????????????????????????????????????????Fedora Extras ???????????? nautilus-open-terminal ???????????????????????????GNOME 2.12 ???????????????????????????????????????????????????????????????????????? Extras ????????? ???????????????????????????????????????????????????????????????????????????????????? rawhide ???????????? MCS SELinux????????????????????????(?????? -- ?????????????????????????????????) OpenOffice ??????????????????????????? ????????????????????? ??????????????????????????? ????????????????????????????????? OpenOffice ???????????? ?????????????????????????????????????????????????????????????????? rm -rf /usr/lib/openoffice.org*/share/template/*/wizard/bitmap
--- NEW FILE development-tools-zh_CN.xml --- --- NEW FILE entertainment-zh_CN.xml ---
??????????????? &FC; ??? &FEX; ????????????????????????????????????????????????&FC; ????????????????????? GNOME ????????????????????? (????????? gnome-games)???????????????????????? yum ????????????????????????????????????????????????????????????????????????????????? yum groupinfo "Games and Entertainment" ???????????? yum ????????????????????????????????????????????????????????????????????? http://fedora.redhat.com/docs/yum/
--- NEW FILE feedback-zh_CN.xml ---
???????????????????????? (???????????? &DISTRO; ?????????????????????????????????????????????) ??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? URL??? %%% https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=<bug-number> %%% ???????????? URL ??????????????????????????????????????????????????????????????????????????? bug ????????????????????? ?????????????????????????????????????????????????????????????????? URL (???????????????????????????????????????)?????????????????????????????? (??????????????? HTML ???????????? — ???????????? URL ?????????)??? ????????????????????????????????????????????? ???????????????????????????????????????????????????????????????????????? http://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=114398 ?????????????????????????????????????????? bugs ????????????????????????????????????????????????????????????????????? ??????????????????????????????
--- NEW FILE file-servers-zh_CN.xml ---
??????????????? ?????????????????? ???????????????????????? &DISTRO; &DISTROVER; ????????? ???????????????????????????????????????????????????????????? &WEB-SERVERS; ??? &SAMBA; ?????????????????? HTTP (Web) ??????????????? Samba (Windows) ????????????????????????
Netatalk (??? Macintosh ??????) ????????????????????? Netatalk ??????????????????Netatalk ????????? Linux ????????? Macintosh ???????????? AppleTalk ??????????????????????????????
<filename>netatalk</filename> &DISTRO; &DISTROVER; ????????? Netatalk ??????????????????????????????????????????????????????????????????????????????Netatalk ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ??? Netatalk ????????????????????????????????? http://netatalk.sourceforge.net/2.0/htmldocs/upgrade.html ?????????????????? netatalk ?????????????????? /usr/share/doc/netatalk-2.0.2/doc/htmldocs/upgrade.html, ??? /usr/share/doc/netatalk-2.0.2/doc/Netatalk-Manual.pdf (???????????? 25, ???????????? 33).
--- NEW FILE hardware-reqs-zh_CN.xml ---
???????????? ?????????????????????????????? &DISTRO; &DISTROVER; ????????????????????????????????? ?????? ??????????????????????????????/????????????????????????????????????????????????????????? (?????????????????????) ???????????????
CPU ?????? ?????????????????? &DISTRO; &DISTROVER; ????????? CPU ????????? ?????? ?????? CPU ???????????? Intel ????????????????????????????????????????????? (??????????????? AMD, Cyrix ??? VIA ?????????) ????????? Intel ????????????????????????????????? &DISTRO;??? ??????????????????????????? — &FC; &LOCALVER; ??????????????? 4 CPU ????????????????????????????????????????????? CPU (???????????????????????????????????? II????????? III???????????? AMD ??? VIA ????????????)????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 4 ???????????????????????????????????????????????? ??????????????????????????????200 MHz ??????????????? ??????????????????????????????400 MHz ?????? II ????????? AMD64 ????????? (?????? Athlon64 ??? Opteron) ?????? Intel Extended Memory 64 Technology (Intel EM64T) ??? Intel ?????????
?????????????????? ???????????????????????? &DISTRO; &DISTROVER; ??????????????? ?????? ?????????????????? &DISTRO; &DISTROVER; ??????????????? ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? (CD-ROM 1 ??????) /Fedora/base/stage2.img ???????????????????????????????????? /var/lib/rpm ???????????? ????????????????????????????????????????????????????????? 90MB ???????????????????????? "everything" ??????????????????????????? 175MB ??????????????? ??????????????????????????????????????????????????????????????? 5% ?????????????????????????????????????????? ??????????????? 32 ??? x86 ????????? ??????????????? (????????????)???620MB ????????????1.1GB ???????????????2.3GB ????????????3.0GB ??????????????? (????????????)???6.9GB ??????????????? 64 ??? x86_64 ????????? ??????????????? (????????????)???900MB ????????????1.5GB ???????????????2.7GB ????????? 3.4GB ??????????????? (????????????)???7.5GB
???????????? ???????????????????????? &DISTRO; &DISTROVER; ??????????????? ??????????????? 32 ??? x86 ????????? ????????????????????????64MB ????????????????????????192MB ????????????????????????256MB ??????????????? 64 ??? x86_64 ????????? ????????????????????????128MB ????????????????????????256MB ????????????????????????512MB
PPC ???????????? ????????????????????? PowerPC (PPC) ????????? &FC; &LOCALVER; ???????????????????????? ????????????PowerPC G3 / POWER4 &FC; &LOCALVER; ????????? Apple ??? 1999 ???????????????????????? New World ????????? Power Macintosh??????????????? 64 ?????? G5 ?????????????????? IBMeServerpSeries ?????? Power ??????????????????????????? 32 ??? IBMRS/6000 ????????? ????????????????????????233MHz G3 ????????? ????????????????????????400MHz G3 ?????????
--- NEW FILE i18n-zh_CN.xml ---
????????? (i18n) SCIM ?????????????????????????????????????????????????????????
??????????????? ?????????????????? &DISTRO; ????????????????????????????????????
IIIMF ???????????? IIIMF ??? Internet/Intranet Input Method Framework?????? &FC; &LOCALVER; ??????iiimf ????????????????????? 12.2 ?????? ????????????????????? iiimf ??????????????????????????????????????????????????????????????? IIIMF ??????????????????????????? /usr/sbin/htt ?????? /usr/bin/iiimd???XIM ??????????????????????????? httx ?????? iiimx???init.d ??????????????????????????????????????????????????? iiim?????????????????????????????????????????? /etc/iiim/??? ???????????? (LE) ???????????????????????????LE ??????????????????????????? ${libdir}/iiim/le/<LE_NAME>/??????????????????????????? /var/lib/iiim/le/<LE_NAME>/??? ?????????????????????????????????????????????????????? Fedora IIIMF FAQ??? http://www.fedora.redhat.com/projects/i18n/iiimf-faq.html. ????????? ?????????????????????????????????????????? CtrlSpace????????????????????????????????? iiimf-le-tools ????????????????????????????????????????????? GTK2 ?????????????????????????????????????????? XIM ??????????????????????????? X ??????????????????????????????????????? IIIMF FAQ ??????????????????????????????????????????????????? http://www.fedora.redhat.com/projects/i18n/iiimf-faq.html??? ?????????????????? X ???????????????????????????????????????????????? Ctrl@ ????????????????????????????????? '<Control>at' ??????????????????????????? '<Control>@'??? ????????? &SEL; enforcing ??????????????????????????? &SEL; ???????????????????????????????????????????????????????????????????????????????????????????????????????????? Qt ?????? ?????????????????? iiimf ??? Qt immodule??????????????????????????????????????????????????????????????????????????????????????????????????????????????? Qt ?????????????????????????????? XIM ????????? IIIMF ????????? ?????????????????? Qt ????????????????????? immodule??????????????? iiimf-qt ???????????????????????????????????????????????????????????????????????????????????????????????? ??????????????? ?????????????????? iiimqcf???
--- NEW FILE install-notes-zh_CN.xml ---
?????? ?????????????????? Anaconda (&DISTRO; ????????????) ??????????????? &DISTRO; &DISTROVER; ???????????????????????? ?????? ????????????????????? &DISTRO; &DISTROVER; DVD ISO ???????????????????????????????????????????????????????????? 2GB ?????????????????????wget ????????? File size limit exceeded ???????????? curl ??? ncftpget ????????????????????????????????????????????????????????? 2GB ???????????? Bittorrent ?????????????????????????????????????????????????????????????????? torrent ???????????????????????? http://torrent.fedoraproject.org/
PPC ??????
PPC ???????????? ????????????????????? PowerPC (PPC) ????????? &DISTRO; &DISTROVER; ???????????????????????? ????????????PowerPC G3 / POWER4 &DISTRO; &DISTROVER; ????????? Apple ??? 1999 ???????????????????????? New World ????????? Power Macintosh??? &DISTRO; &DISTROVER; ????????? IBM eServer pSeries???IBM RS/6000 ?????? Genesi Pegasos II ???????????? ????????????????????????233MHz G3 ????????????64MB ?????? ????????????????????????400MHz G3 ????????????128MB ?????? &FC; ??????????????? DVD ???????????? CD ????????????????????????????????????????????????????????????????????? DVD ???????????? CD ??? images/ ???????????????????????? CD ??????????????????????????????????????????????????? ??????????????????????????????????????? Apple Macintosh ??????????????????????????????????????? 32 ?????? 64 ???????????????????????????????????????????????????????????????????????????????????? apmud ???????????????????????? &FEX; ??????????????? &FC; ????????? &FEX; ???????????? yum ?????????????????????????????????????????? yum install apmud ????????? apmud??? 64-bit IBM eServer pSeries (POWER4/POWER5) ?????? OpenFirmware ?????? CD ????????????????????? (yaboot) ?????????????????? 64 ????????????????????? 32-bit CHRP (IBM RS/6000 ?????????) ?????? OpenFirmware ?????? CD ????????? boot: ?????????????????? linux32 ????????????????????? 32 ??????????????????????????????64 ?????????????????????????????????????????????????????? Genesi Pegasos II ?????? &DISTRO; &DISTROVER;????????? Pegasos ?????? ISO9660 ??????????????????????????????????????????????????????????????????????????? OpenFirmware ?????????????????????????????? boot cd: /images/netboot/ppc32.img ???????????????????????? Pegasos ?????? OpenFirmware ?????????????????? &FC; ???????????????????????????????????? boot-device ??? boot-file ?????????????????????????????? ???????????? ??????????????? images/netboot/ ???????????????????????????????????? ramdisk ????????????????????????????????????????????? TFTP ????????????????????????????????????????????????????????? yaboot ?????? IBM eServer pSeries ??? Apple Macintosh ?????? tftp ?????????&FED; ???????????? yaboot ????????? netboot ???????????????
???????????? Anaconda &DISTRO; ??????????????????????????????????????????????????????????????? CD, DVD, ????????????????????? NFS ??????????????????????????????&RH; ???????????????????????????????????????????????????????????? bugs ????????????????????????????????? (??????????????????????????????????????? CD ??????????????????)???????????????????????? boot: ?????????????????? linux mediacheck??? mediacheck ??????????????????????????????????????????????????????????????????????????????????????????????????????????????? ISO ??????????????????????????????????????? padding???????????? mediacheck ??????????????????????????????????????????????????? linux ide=nodma ????????????????????? sha1sum ???????????????????????????????????????????????????????????????????????? ISO ????????????????????? ????????? boot: ?????????????????? memtest86???????????? &DISTRO; ????????????????????????????????? Memtest86 ???????????????????????????Memtest86 ????????????????????????????????? Esc ?????? ?????????????????? CD-ROM 1 (????????? CD-ROM) ???????????????????????????????????? &DISTRO; &DISTROVER; ?????????????????? FTP ??? HTTP ???????????????????????????????????????????????????????????????????????????????????? 128MB ??????????????? (???????????????????????????????????????????????? CD-ROM 1 ???????????????) ???????????????????????????????????? 128MB ???????????????????????????????????????????????????????????????
????????????????????? ?????????????????? (??????????????? LCD ??????????????????) ??????????????? &DISTRO; ???????????????????????????????????????????????????????????????????????????????????? "nofb" ????????? ?????? ????????????????????????????????????????????????????????? "nofb" ????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????? Sony VAIO ????????????????????????????????? &DISTRO; ????????????????????????????????????????????????????????????????????????????????????????????????????????? pci=off ide1=0x180,0x386 ????????????????????????????????????????????????????????????????????????????????????????????????????????? &DISTRO; ????????????????????????????????? ?????????????????????????????????????????????????????????????????????????????? X ???????????????????????? bug #119474 ???????????????????????? http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119474 ????????? &RHL; 7.<x>, 8.0, 9, ?????? &FC; 1, 2 ??? 3 ???????????????????????????????????????????????? &FP; ???????????????????????????????????????????????????????????? Ximian GNOME??? Ximian GNOME ??????????????????????????? &RHL; (???????????? &PROJ; ???) RPMs ??? Ximian RPMs ?????????????????????????????????????????????????????????????????????????????? ?????????????????? &DISTRO; ??????????????????????????? Ximian GNOME ????????????????????????????????????????????? Ximian GNOME ??????????????????????????????????????? Ximian GNOME ???????????? RPMs???????????????????????? &DISTRO; RPMs ????????????????????????????????????????????????????????????????????????????????????????????? GNOME ??????
--- NEW FILE intro-zh_CN.xml ---
?????????????????????????????? &PROJ; ???????????? &RH; ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? &DISTRO;?????????????????????????????????????????????????????????????????????????????????????????????????????? ?????? &FC; ????????????????????????????????? &FC; ?????? &FORMAL-RHI; ??????????????????????????? ?????????????????????????????? ??? ??????????????????????????????????????????????????? http://fedora.redhat.com/docs/release-notes/ ??????????????????????????????????????????????????????????????? ??????????????????????????????????????????????????????????????? ??????????????? bugzilla ?????? ??????????????? bug ????????? ????????????????????? &TINY-BUG-URL; ?????????????????????????????? bugzilla ?????????
--- NEW FILE java-package-zh_CN.xml ---
?????? Java ????????? ?????????????????? ???????????????????????? &DISTRO; &DISTROVER; ????????? &FC; &LOCALVER; ????????????????????? Sun ????????? Java RPM??????????????? Provides ????????? &FC; &LOCALVER; ??????????????????????????????????????????????????????????????????????????????????????????????????????????????? Sun Java ????????????????????? &FC; &LOCALVER; ?????????????????? jpackage.org ????????? RPM ??????????????? Sun Java tar ??????????????? /opt ????????????
--- NEW FILE kernel-zh_CN.xml ---
Linux ??????
?????? &DISTRO; ?????? 2.6 ??????????????????&FC; ????????????????????????????????????????????????????????????????????????????????????&FC; ???????????? kernel.org ???????????????????????????????????? vanilla kernel ????????????????????????????????? ????????? &FC; ??????????????????????????????????????????????????????????????? rpm -qplkernel-version.src.rpm
???????????? &FC; ??????????????????????????? ??????????????????????????????????????? SMP ??????????????????????????????????????? kernel-devel-version.arch.rpm ??????????????? ??????????????????????????? Xen ?????????????????????????????????????????? kernel-xen0-devel-version.arch.rpm ??????????????? ????????????????????????????????????????????????????????????????????? /usr/src/kernels/version[-xen0]-arch/ ??????????????????????????????????????? rpm -Uvhkernel-devel[-xen0]-version.arch.rpm ??? ?????????????????????????????? ?????? Linux ????????????????????????????????????????????????????????????????????????????????? /usr/src/linux ???????????????????????????????????????????????????????????????????????? &FC; ??????????????????????????????????????????????????????????????????????????????????????????????????????????????? ln -s/usr/src/kernels/kernel-all-the-rest/usr/src/linux
???????????????????????? &DISTRO; &DISTROVER; ?????????????????????????????? kernel-source ????????????????????????????????????????????? ????????????????????? &FC; ????????????????????????????????? kernel.src.rpm ???????????????????????????????????????????????????????????????????????????????????????????????? ???????????????????????????????????????????????? ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? version ??????????????????????????????????????????????????? uname -r ??????????????????????????? kernel-version.src.rpm ????????? ????????? SRPMSCDISO ?????????????????? SRPMS ?????? ???????????????????????? FTP ?????? ???????????????????????? up2date --get-sourcekernel ?????????????????????????????? kernel-version.src.rpm??? rpm -Uvhkernel-version.src.rpm ????????? RPM ???????????? /usr/src/redhat/SOURCES ??? /usr/src/redhat/SPECS ????????? ???????????????????????????????????????????????? cd /usr/src/redhat/SPECS rpmbuild -bp --target $(arch)kernel-2.6.spec ???????????????????????? /usr/src/redhat/BUILD/kernel-version ??????????????????????????????????????? linux-version ???????????? /usr/src ????????????????????????????????????????????????????????????????????????????????????????????? cd /usr/src/redhat/BUILD/kernel-version/usr/src/ mv linux-version/usr/src/ cd /usr/src ln -s./linux-versionlinux cd /usr/src/linux &DISTRO; &DISTROVER; ????????????????????????????????? configs/ ??????????????????i686 SMP ???????????????????????? configs/kernel-version-i686-smp.config?????????????????????????????????????????????????????????????????????????????????????????? cp configs/desired-config-file.config ??????????????? /lib/modules/version/build/.config ???????????????????????????????????????????????? .config ????????? ?????????????????????????????????????????????????????? uname -r ??????????????????????????? Makefile ?????????????????????????????????????????????????????????????????????????????????Makefile ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? Makefile??? ??????????????? uname -r ????????????????????? 2.6.11-1.234_FC4???????????? EXTRAVERSION ??????????????? EXTRAVERSION = -prep ???????????? EXTRAVERSION = -1.234_FC4 ?????????????????????????????????????????????????????????????????? ????????????????????? make oldconfig ?????????????????????????????????
????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????? ??????????????????????????? ?????????????????? foo.ko ?????????????????? foo.c ????????????????????????????????? Makefile??? obj-m := foo.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) default: $(MAKE) -C $(KDIR) M=$(PWD) modules ?????? make ??????????????? foo.ko ?????????????????????
?????????????????????????????? &DISTRO; ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ??????????????????????????????????????????????????? rpm -e kernel-version ???????????????????????????????????????????????????????????????????????????????????? rpm -e ???????????????????????????????????????????????????????????????????????????????????????????????? yum remove kernel-version????????? yum ?????????????????????????????????????????????
--- NEW FILE legacy-zh_CN.xml --- --- NEW FILE misc-server-zh_CN.xml ---
???????????? ??????????????????????????????????????????????????????????????????????????????
OpenOffice ??????????????????????????? ????????????????????? ??????????????????????????? ????????????????????????????????? OpenOffice ???????????? ?????????????????????????????????????????????????????????????????? rm -rf /usr/lib/openoffice.org*/share/template/*/wizard/bitmap
--- NEW FILE multimedia-zh_CN.xml ---
????????? &FC; ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????? &FEX; ??????????????? ?????????????????? &FC; ???????????? rhythmbox???totem ??? Helix Player (hxplay) ??????????????????????????????&FC; ??? &FEX; ??????????????????????????????????????????????????? xmms ????????????GNOME ??? KDE ????????????????????????????????????????????????????????????????????????????????? Adobe/Macromedia ??? Flash ????????????Real Player???VLC???MPlayer ??? Xine ???????????????????????????????????????????????? &FED; ?????????????????????????????? &FED; ???????????????????????????????????????????????????????????????????????????????????? ??????????????? &FC; ?????????????????????????????? Linux ???????????? (ALSA) ?????????????????????????????????????????????????????????????????? Linux ????????????????????????????????????????????????????????????????????????????????? ALSA ?????????????????????????????????????????????????????????????????????????????????????????????????????? http://www.alsa-project.org/ Ogg ??? Xiph.Org ???????????????????????? Fedora ???????????? Ogg ?????????????????????????????????????????? Vorbis ?????????Theora ?????????Speex ????????? FLAC ???????????????????????????????????????????????????????????????????????????????????????????????? Xiph.Org ????????????????????? http://www.xiph.org/ MP3 ??? DVD ?????? &FC; ??? &FEX; ??????????????? MP3 ??? DVD ???????????????????????????????????? MP3 ??? MPEG (DVD) ???????????????????????????????????????????????????????????????????????????????????????????????? ???
?????????????????? ???????????????????????????????????????????????? &FC; ??? &FEX; ???????????????????????????????????? MP3 ??? DVD ??????????????????Flash ???????????? Real ??????????????????????????????????????????????????????????????????????????????????????????????????????????????????Fedora ??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? http://fedoraproject.org/wiki/ForbiddenItems
CD ??? DVD ??????????????? &FC; ??? &FEX; ????????????????????????????????? CD ??? DVD ??????????????????????????????????????????????????? cdrecord???readcd???mkisofs ???????????? Linux ???????????????GNOME ?????????????????? &FC; ?????? xcdroast ??? &FEX; ?????? graveman ??????????????????????????????????????????KDE ?????????????????? k3b????????????????????????????????????
--- NEW FILE networking-zh_CN.xml ---
?????? ????????????????????? 2.6.11 - 2.6.14 IPv4 ???????????? ???????????? 2.6.12 ??????????????????????????????????????????????????????????????????????????????????????? IPv4 ?????????????????????????????????????????????????????????????????????????????????????????????????????? sysctl (??????????????????????????????) ????????????????????????????????????????????????????????? ICMP ?????????????????????????????? ????????? ICMP ?????????????????????????????????????????????????????? ICMP ?????????????????????????????? 2.6.12 ????????????????????? sysctl???????????????????????????????????????????????????????????????????????? ?????????????????? eth0 ???????????? ICMP ?????????????????????????????? sysctl ??????????????????????????? ICMP ?????????????????? eth1 ??????????????? eth0 ?????????????????????????????????????????? eth1 ???????????? ????????????????????????????????????????????????????????? ?????? LC-Trie ????????????????????? ?????????????????? trie ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????? TCP ???????????????????????????????????????????????????????????????????????? new RENO ???????????????????????????????????????????????????????????????????????????????????? ?????? TCP ???????????? TCP Hybla ???????????? H-TCP ???????????? ????????? TCP ???????????? ?????????????????????????????????????????????????????????????????????BIC ??????????????? BICTCP 1.1 ???????????????????????????????????????????????? ???????????????????????? ???????????????????????????????????????????????????????????????????????? ??????????????????????????????????????? ????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? DCCP ???????????? ?????? 2.6.14-rc1 ??????????????? DCCP ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????? ???????????? HostAP ???????????????????????? 2.6.14-rc1 ????????????????????????????????????????????????????????????????????????????????? Intersil Prism2 ????????? (PC Card/PCI/PLX)?????????????????? Intel(R) PRO/Wireless 2100 ??? 2200 ???????????????????????? ?????? ????????? TCP ???????????? (TSO) ?????????????????????????????? ????????????????????????????????????????????????????????? iptables ???????????????????????? ????????????????????? IPv4 ??? IPv6 ??????????????????????????????????????????????????????????????? IPv4 ?????????????????? SNMPv2 MIB ????????? ipInAddrErrors ???????????? ??? Advanced API (RFC3542) ???????????????????????????????????????????????????
????????????????????? iproute ?????????????????? 2.6.12???IPv4 ???????????????????????????????????????????????????????????????????????????????????????????????????iproute2 ??????????????????????????????????????????????????? ip addr list dev eth0 4: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 inet 10.0.0.3/24 scope global eth0 su -c 'ip addr del 10.0.0.3 dev eth0' Warning: Executing wildcard deletion to stay compatible with old scripts. Explicitly specify the prefix length (10.0.0.3/32) to avoid this warning. This special behaviour is likely to disappear in further releases, fix your scripts! ??????????????????????????????????????????????????? su -c 'ip addr del 10.0.0.3/24 dev eth0' ????????????????????????????????????????????????????????????????????????????????????????????? (???????????????)????????? NO-CARRIER ???????????????????????????????????????????????????????????????????????????????????????????????? ip ?????????????????????????????? ??????????????????????????? tc ?????????????????????????????????????????????
--- NEW FILE overview-zh_CN.xml ---
?????????????????? ?????????????????? ???????????????????????? &DISTRO; &DISTROVER; ?????????
--- NEW FILE package-movement-zh_CN.xml ---
??????????????? ????????????????????????????????????????????????????????????????????? \ ??????????????????????????????????????????????????? treediff.py dist-fc4 dist-rawhide > /tmp/diff \ sed -e 's,^,* ,g' -e 's,$,\n,g' /tmp/diff > diffwiki
?????????????????? ?????? 2005 ??? 9 ??? 21 ??? [106429] MAKEDEV-3.19-1 -> [115423] MAKEDEV-3.19-4 [111566] ImageMagick-6.2.2.0-2 -> [112246] ImageMagick-6.2.2.0-4 [105261] newt-0.51.6-7 -> [117695] newt-0.51.6-8 [106878] am-utils-6.0.9-12 -> [117066] am-utils-6.1.1-2 [108819] amanda-2.4.5-2 -> [115871] amanda-2.4.5-3 [112105] anaconda-10.2.1.5-2 -> [118390] anaconda-10.3.0.24-1 [105300] aspell-0.50.5-6 -> [114172] aspell-0.60.3-2 [108035] aspell-ca-0.50-2 -> [114184] aspell-ca-0.50-4 [108036] aspell-cs-0.51-2 -> [114270] aspell-cs-0.51-3 [108038] aspell-da-0.50-11 -> [114276] aspell-da-0.50-12 [106443] libsoup-2.2.3-2 -> [116988] libsoup-2.2.6.1-1 [108042] aspell-es-0.50-11 -> [117058] aspell-es-0.50-13 [108044] aspell-fr-0.50-8 -> [114285] aspell-fr-0.50-9 [108051] aspell-it-0.53-2 -> [114362] aspell-it-0.53-3 [108055] aspell-nl-0.50-6 -> [114363] aspell-nl-0.50-7 [108058] aspell-no-0.50.1-8 -> [114366] aspell-no-0.50.1-9 [108060] aspell-pl-0.51-3 -> [118018] aspell-pl-0.51-5 [108061] aspell-sv-0.50-7 -> [114371] aspell-sv-0.50-8 [107959] at-3.1.8-77_FC4 -> [112026] at-3.1.8-78 [108132] gtkhtml3-3.6.2-1 -> [117587] gtkhtml3-3.8.0-1 [108304] ntp-4.2.0.a.20040617-8 -> [117060] ntp-4.2.0.a.20050816-1 [108909] autofs-4.1.4-5 -> [112718] autofs-4.1.4-9 [102923] automake-1.9.5-1 -> [114414] automake-1.9.6-1 [108562] autorun-3.16-1 -> [118091] autorun-3.17-1 [105321] awesfx-0.5.0d-2 -> [113536] awesfx-0.5.0d-3 [105808] nut-2.0.1-1 -> [114509] nut-2.0.2-1 [110344] bash-3.0-31 -> [118423] bash-3.0-34 [110908] bind-9.3.1-4 -> [116915] bind-9.3.1-11 [111486] binutils-2.15.94.0.2.2-2 -> [116754] binutils-2.16.91.0.2-4 [105319] bootparamd-0.17-22.devel -> [116780] bootparamd-0.17-23.devel [106988] bug-buddy-2.10.0-1 -> [117633] bug-buddy-2.12.0-1 [111028] bzip2-1.0.2-16 -> [117182] bzip2-1.0.3-1 [106470] pax-3.0-11 -> [116422] pax-3.4-1 [109185] SysVinit-2.85-39 -> [113360] SysVinit-2.85-40 [111393] control-center-2.10.1-6 -> [118105] control-center-2.12.0-2 [111120] openldap-2.2.23-5 -> [111936] openldap-2.2.26-1 [110745] cpio-2.6-7 -> [113389] cpio-2.6-8 [106419] cracklib-2.8.2-1 -> [111862] cracklib-2.8.3-1 [104496] bluez-hcidump-1.18-1 -> [115995] bluez-hcidump-1.24-1 [104877] ctags-5.5.4-3 -> [115419] ctags-5.5.4-4 [108614] cvs-1.11.19-8 -> [116935] cvs-1.11.19-10 [108252] cyrus-sasl-2.1.20-5 -> [117833] cyrus-sasl-2.1.21-5 [109650] pam-0.79-8 -> [118330] pam-0.80-8 [109663] dhcp-3.0.2-12 -> [117972] dhcp-3.0.3-6 [110743] apr-0.9.6-3 -> [118164] apr-0.9.6-6 [110347] e2fsprogs-1.37-4 -> [117739] e2fsprogs-1.38-1 [104668] diffstat-1.38-2 -> [116208] diffstat-1.38-4 [107298] doxygen-1.4.2-1 -> [118248] doxygen-1.4.4-2 [110505] dump-0.4b40-2 -> [113542] dump-0.4b40-4 [110508] eject-2.0.13-15 -> [117061] eject-2.1.2-1 [110262] parted-1.6.22-2 -> [117238] parted-1.6.24-1 [110911] emacs-21.4-5 -> [114092] emacs-21.4-7 [111808] esound-0.2.35-5 -> [114327] esound-0.2.36-1 [105304] passwd-0.69-2 -> [112701] passwd-0.70-1 [106286] fetchmail-6.2.5-7 -> [114678] fetchmail-6.2.5.2-1 [109759] patch-2.5.4-24 -> [117794] patch-2.5.4-29 [111272] filesystem-2.3.4-1 -> [116817] filesystem-2.3.5-1 [106330] findutils-4.2.20-1 -> [117490] findutils-4.2.25-2 [105012] finger-0.17-28 -> [113967] finger-0.17-29 [105097] freetype-2.1.9-2 -> [116586] freetype-2.1.9-4 [111401] ftp-0.17-26 -> [117241] ftp-0.17-29 [104499] gawk-3.1.4-5 -> [118359] gawk-3.1.5-2 [111099] gcc-4.0.0-8 -> [118294] gcc-4.0.1-14 [108458] gd-2.0.33-2 -> [117628] gd-2.0.33-3 [109684] gdb-6.3.0.0-1.21 -> [117661] gdb-6.3.0.0-1.65 [106626] gettext-0.14.3-1 -> [116274] gettext-0.14.5-1 [111402] gdm-2.6.0.8-16 -> [117776] gdm-2.8.0.4-1 [108333] gedit-2.10.2-3 -> [117719] gedit-2.12.0-1 [110935] perl-5.8.6-15 -> [117489] perl-5.8.7-0.3.fc5 [107237] gok-1.0.3-1 -> [116496] gok-1.0.5-4 [110356] php-5.0.4-10 -> [118097] php-5.0.5-3 [110581] gimp-2.2.7-4 -> [116538] gimp-2.2.8-3 [111654] gnome-applets-2.10.1-9 -> [117721] gnome-applets-2.12.0-1 [111691] glibc-2.3.5-10 -> [117966] glibc-2.3.90-12 [111104] gnome-games-2.10.0-5 -> [117724] gnome-games-2.12.0-1 [111214] gnome-media-2.10.2-4 -> [117726] gnome-media-2.12.0-1 [106508] kdeadmin-3.4.0-1 -> [118336] kdeadmin-3.4.2-2 [110919] gnome-utils-2.10.0-3 -> [117738] gnome-utils-2.12.0-1 [110246] gnupg-1.4.1-3 -> [116120] gnupg-1.4.2-3 [104528] gnuplot-4.0.0-7 -> [117403] gnuplot-4.0.0-8 [104506] gperf-3.0.1-6 -> [115552] gperf-3.0.1-7 [104548] grep-2.5.1-48 -> [113236] grep-2.5.1-50 [108057] xinitrc-4.0.18-1 -> [111974] xinitrc-4.0.19-1 [104544] guile-1.6.7-2 -> [117402] guile-1.6.7-4 [104475] hdparm-5.9-1 -> [112183] hdparm-6.1-1 [111501] initscripts-8.11.1-1 -> [117977] initscripts-8.14-1 [107880] inn-2.4.2-3 -> [115559] inn-2.4.2-4 [106114] iproute-2.6.11-1 -> [118247] iproute-2.6.14-3 [106499] iptables-1.3.0-2 -> [114287] iptables-1.3.2-1 [107881] iputils-20020927-22 -> [117698] iputils-20020927-26 [111656] isdn4k-utils-3.2-28 -> [115009] isdn4k-utils-3.2-32 [105032] joe-3.1-8 -> [112056] joe-3.3-1 [108237] kdebase-3.4.0-5 -> [118422] kdebase-3.4.2-5 [106532] kdegames-3.4.0-1 -> [116019] kdegames-3.4.2-1 [107198] kdegraphics-3.4.0-2 -> [117508] kdegraphics-3.4.2-3 [104526] openobex-1.0.1-3 -> [111937] openobex-1.0.1-4 [107226] kdemultimedia-3.4.0-2 -> [115553] kdemultimedia-3.4.2-1 [106551] kdeutils-3.4.0-1 -> [117699] kdeutils-3.4.2-2 [105322] minicom-2.00.0-21 -> [114175] minicom-2.1-1 [112015] kernel-2.6.11-1.1369_FC4 -> [118394] kernel-2.6.13-1.1565_FC5 [108707] libbtctl-0.4.1-7 -> [114382] libbtctl-0.4.1-8 [107067] krb5-1.4-3 -> [118053] krb5-1.4.2-4 [106252] krbafs-1.2.2-7 -> [115422] krbafs-1.2.2-8 [111032] kudzu-1.1.116.2-2 -> [118290] kudzu-1.2.7-1 [105596] lam-7.1.1-3 -> [115564] lam-7.1.1-7.FC5 [105047] less-382-7 -> [117533] less-382-8 [104599] libieee1284-0.2.9-2 -> [114409] libieee1284-0.2.9-3 [106523] libtermcap-2.0.8-41 -> [115467] libtermcap-2.0.8-42 [110440] libtiff-3.7.1-6 -> [113273] libtiff-3.7.2-1 [109070] libtool-1.5.16.multilib2-1 -> [118098] libtool-1.5.20-3 [104597] lm_sensors-2.8.8-5 -> [117365] lm_sensors-2.9.1-4 [105199] lockdev-1.0.1-7 -> [118409] lockdev-1.0.1-9 [107338] logrotate-3.7.1-10 -> [117629] logrotate-3.7.2-3 [110353] lsof-4.74-7 -> [118297] lsof-4.76-1 [108835] dovecot-0.99.14-4.fc4 -> [114740] dovecot-0.99.14-6.fc5 [106781] make-3.80-7 -> [116850] make-3.80-8 [104365] distcache-1.4.5-7 -> [115345] distcache-1.4.5-11 [107530] man-pages-1.67-7 -> [118017] man-pages-2.07-5 [93204] man-pages-cs-0.16-4 -> [115882] man-pages-cs-0.16-5 [93194] man-pages-de-0.4-9 -> [115873] man-pages-de-0.4-10 [108613] man-pages-ja-20050415-1 -> [116660] man-pages-ja-20050815-1 [110081] mx4j-2.1.0-1jpp_7fc -> [114677] mx4j-3.0.1-1jpp_5fc [109945] mc-4.6.1a-0.9 -> [118021] mc-4.6.1a-0.15 [101562] desktop-file-utils-0.10-1 -> [117302] desktop-file-utils-0.10-3 [111217] redhat-artwork-0.122-10 -> [116975] redhat-artwork-0.128-1 [104435] mikmod-3.1.6-34 -> [112072] mikmod-3.1.6-35 [110923] mkinitrd-4.2.15-1 -> [116471] mkinitrd-4.2.21-1 [110244] gimp-print-4.2.7-7 -> [116481] gimp-print-4.2.7-12 [111409] rhpl-0.167-1 -> [118384] rhpl-0.174-1 [108728] glade2-2.10.0-1 -> [116544] glade2-2.10.0-2 [107181] pyxf86config-0.3.19-4 -> [114209] pyxf86config-0.3.19-6 [105582] arptables_jf-0.0.8-4 -> [116740] arptables_jf-0.0.8-6 [108583] fontconfig-2.2.3-13 -> [114861] fontconfig-2.3.2-1 [108241] oprofile-0.8.2-4 -> [114916] oprofile-0.9.1-2 [104605] mtr-0.69-3 -> [117503] mtr-0.69-4 [105384] mutt-1.4.2.1-2 -> [117134] mutt-1.4.2.1-3 [106486] kdeedu-3.4.0-1 -> [118428] kdeedu-3.4.2-3 [111281] httpd-2.0.54-10 -> [115215] httpd-2.0.54-12 [109664] libwpd-0.8.1-1 -> [117298] libwpd-0.8.3-1 [109161] ncurses-5.4-17 -> [115668] ncurses-5.4-18 [109016] net-tools-1.60-52 -> [115663] net-tools-1.60-56 [106997] rdesktop-1.4.0-2 -> [113322] rdesktop-1.4.1-1.fc5 [106852] redhat-rpm-config-8.0.34-1 -> [116588] redhat-rpm-config-8.0.39-1 [104517] compat-slang-1.4.5-10 -> [115421] compat-slang-1.4.5-11 [111646] nfs-utils-1.0.7-8 -> [117732] nfs-utils-1.0.7-16 [104611] rarpd-ss981107-20 -> [114929] rarpd-ss981107-22 [111216] nss_ldap-234-4 -> [117936] nss_ldap-241-1 [101793] squirrelmail-1.4.4-2 -> [117917] squirrelmail-1.4.6-0.cvs20050812.2.fc5 - perl-Filter-1.30-7 - perl-Filter-Simple-0.79-5 [111400] libxslt-1.1.14-2 -> [117480] libxslt-1.1.15-1 [111035] pam_krb5-2.1.7-3 -> [115747] pam_krb5-2.1.8-2 [106493] file-roller-2.10.0-1 -> [117656] file-roller-2.12.0-1 [106353] pyOpenSSL-0.6-1.p24.4 -> [117052] pyOpenSSL-0.6-1.p24.6 [104627] rdist-6.1.5-40 -> [111944] rdist-6.1.5-41 [110926] spamassassin-3.0.3-4.fc4 -> [118074] spamassassin-3.1.0-1.fc5 [105950] pilot-link-0.12.0-0.pre2.0 -> [117233] pilot-link-0.12.0-0.pre4.5 [106474] star-1.5a54-2 -> [117115] star-1.5a65-1 [111515] net-snmp-5.2.1-12 -> [118322] net-snmp-5.2.1.2-3 [96116] ppp-2.4.2-7 -> [115416] ppp-2.4.3-3 [110366] vlock-1.3-19 -> [115661] vlock-1.3-20 [110359] procps-3.2.5-6 -> [117548] procps-3.2.5-7 [105210] psmisc-21.5-4 -> [117707] psmisc-21.6-1 [105614] pvm-3.4.5-3_FC4 -> [111812] pvm-3.4.5-5 [105105] bogl-0.1.18-7 -> [118318] bogl-0.1.18-10 [108185] gnopernicus-0.10.6-1 -> [117638] gnopernicus-0.11.6-1 [110883] qt-3.3.4-14 -> [118419] qt-3.3.5-2 [104494] ksh-20050202-1 -> [111912] ksh-20050202-3 [108083] quota-3.12-6 -> [116742] quota-3.12-7 [101735] gnome-speech-0.3.6-1 -> [115904] gnome-speech-0.3.7-1 [111387] openoffice.org-1.9.104-2 -> [118196] openoffice.org-1.9.130-1.2.fc5 [105350] rp-pppoe-3.5-27 -> [116414] rp-pppoe-3.5-30 [111410] rpm-4.4.1-21 -> [117156] rpm-4.4.2-4 [110925] rsync-2.6.4-3 -> [115264] rsync-2.6.6-2 [104630] rusers-0.17-43 -> [117620] rusers-0.17-45 [109533] samba-3.0.14a-2 -> [117971] samba-3.0.20-2 - sash-3.7-6 [110268] sendmail-8.13.4-2 -> [118253] sendmail-8.13.5-1 [111123] setup-2.5.44-1 -> [117568] setup-2.5.47-1.1 [111408] shadow-utils-4.0.7-9 -> [117343] shadow-utils-4.0.12-2 [106465] slang-1.4.9-17 -> [117492] slang-1.4.9-19 [108441] slocate-2.7-22 -> [118067] slocate-2.7-27 [105316] slrn-0.9.8.1-4 -> [114996] slrn-0.9.8.1-5 [110665] squid-2.5.STABLE9-7 -> [117506] squid-2.5.STABLE10-4 [106754] strace-4.5.11-1 -> [115667] strace-4.5.13-1 [108145] sudo-1.6.8p8-1 -> [118285] sudo-1.6.8p9-4 [93654] switchdesk-4.0.6-3 -> [114432] switchdesk-4.0.7-1 [111041] sysklogd-1.4.1-30 -> [117045] sysklogd-1.4.1-33 [112528] syslinux-3.08-2 -> [117044] syslinux-3.10-2 [110362] sysreport-1.4.1-2 -> [112702] sysreport-1.4.1-4 [105297] sysstat-5.0.5-9.fc -> [116738] sysstat-5.0.5-11.fc [108370] tar-1.15.1-5 -> [117554] tar-1.15.1-10 [109655] tcpdump-3.8.2-12 -> [116178] tcpdump-3.9.3-3 [106994] tcsh-6.14-1 -> [115897] tcsh-6.14-5 [106284] termcap-5.4-4 -> [118201] termcap-5.4-7 [110274] tetex-3.0-4 -> [116781] tetex-3.0-6 [106019] texinfo-4.8-4 -> [112242] texinfo-4.8-6 [109641] jwhois-3.2.2-14 -> [115889] jwhois-3.2.3-2 [110348] elfutils-0.108-1 -> [117517] elfutils-0.115-1 [105286] expect-5.43.0-1 -> [111871] expect-5.43.0-2 [105014] traceroute-1.4a12-26 -> [116290] traceroute-1.4a12-27 [108240] subversion-1.1.4-3 -> [117737] subversion-1.2.3-3 - schedutils-1.4.0-4 [106314] umb-scheme-3.2-38 -> [117616] umb-scheme-3.2-39 [104847] units-1.80-12 -> [114388] units-1.85-1 [107560] quagga-0.98.3-2 -> [117222] quagga-0.98.5-2 [105298] unzip-5.51-10 -> [115669] unzip-5.51-12 [109681] util-linux-2.12p-9.3 -> [117509] util-linux-2.13-0.3.pre2 [108550] uucp-1.07-9 -> [114161] uucp-1.07-11 [109140] vim-6.3.071-3 -> [117700] vim-6.3.086-5 [108347] vixie-cron-4.1-33 -> [113831] vixie-cron-4.1-36.FC5 [106439] gtksourceview-1.2.0-1 -> [117747] gtksourceview-1.4.1-1 [109142] vnc-4.1.1-10 -> [117547] vnc-4.1.1-17 - w3c-libwww-5.4.0-13 [104493] wget-1.9.1-22 -> [117731] wget-1.10.1-7 [100923] wireless-tools-28-0.pre4.3 -> [117952] wireless-tools-28-0.pre9.5 [104447] neon-0.24.7-6 -> [118267] neon-0.24.7-7 [108529] desktop-printing-0.18-10 -> [116635] desktop-printing-0.19-2 [109757] libselinux-1.23.10-2 -> [118218] libselinux-1.26-6 [110975] xfig-3.2.4-11 -> [114406] xfig-3.2.4-13 [106604] ttmkfdir-3.0.9-16 -> [115679] ttmkfdir-3.0.9-17 [106293] ckermit-8.0.211-1 -> [117400] ckermit-8.0.211-3 [111493] coreutils-5.2.1-48 -> [117826] coreutils-5.2.1-55 [109668] gstreamer-0.8.10-1 -> [117857] gstreamer-0.8.11-1 [110247] gstreamer-plugins-0.8.8-6 -> [117858] gstreamer-plugins-0.8.11-1 [108260] gnome-icon-theme-2.10.1-4 -> [117725] gnome-icon-theme-2.12.0-1 [111290] xpdf-3.00-19 -> [116734] xpdf-3.01-1 [104699] xsane-0.95-3 -> [112799] xsane-0.95-4 [110438] xscreensaver-4.21-4 -> [118219] xscreensaver-4.22-16 [106575] nautilus-cd-burner-2.10.0-2 -> [117669] nautilus-cd-burner-2.12.0-1 - hpoj-0.91-13 [108081] ypserv-2.13-6 -> [114545] ypserv-2.13-7 [108065] zlib-1.2.2.2-3 -> [117021] zlib-1.2.3-1 [110759] gthumb-2.6.5-1 -> [117742] gthumb-2.6.7-1 [110698] alsa-utils-1.0.9rc2-2 -> [116939] alsa-utils-1.0.9rf-5 [111418] libgnomeprint22-2.10.3-1 -> [117675] libgnomeprint22-2.12.0-1 [106542] libgnomeprintui22-2.10.1-1 -> [117676] libgnomeprintui22-2.12.0-1 [106076] rhythmbox-0.8.8-2 -> [117443] rhythmbox-0.9.0.cvs20050902-1 [104518] libgsf-1.11.1-2 -> [118324] libgsf-1.12.3-1 [104645] libmng-1.0.9-1 -> [112902] libmng-1.0.9-2 [104492] bluez-libs-2.15-1 -> [117512] bluez-libs-2.20-1 [109626] bluez-utils-2.15-7 -> [117513] bluez-utils-2.20-1 [109284] gnome-themes-2.10.1-2 -> [117637] gnome-themes-2.12.0-1 [106333] lv-4.51-5 -> [113778] lv-4.51-6 [106337] nkf-2.04-5 -> [113596] nkf-2.05-1 - nvi-m17n-1.79-20040401.23 [108025] ruby-1.8.2-7 -> [118404] ruby-1.8.3-1 [109083] stunnel-4.08-2 -> [113854] stunnel-4.11-1 [108440] 4Suite-1.0-8.b1 -> [112368] 4Suite-1.0-9.b1 [106235] nss_db-2.2-31 -> [117271] nss_db-2.2-33 [111212] eclipse-3.1.0_fc-0.M6.22 -> [115167] eclipse-3.1.0_fc-12 [111394] dbus-0.33-3 -> [117773] dbus-0.50-1 [106803] a2ps-4.13b-46 -> [111842] a2ps-4.13b-47 [109643] libuser-0.53.7-1 -> [117997] libuser-0.54-1 [109886] gtk-doc-1.3-2 -> [113533] gtk-doc-1.4-1 [109144] perl-DBD-MySQL-2.9007-1 -> [117217] perl-DBD-MySQL-3.0002-1 [111122] perl-DBD-Pg-1.41-2 -> [113244] perl-DBD-Pg-1.43-1 [105244] kdbg-1.2.10-2 -> [114272] kdbg-2.0.0-1 [106810] kdepim-3.4.0-4 -> [117234] kdepim-3.4.2-3 [106772] xdelta-1.1.3-16 -> [117821] xdelta-1.1.3-17 [107253] pkgconfig-0.15.0-6 -> [116158] pkgconfig-0.18.1-4 [108628] kdesdk-3.4.0-3 -> [116008] kdesdk-3.4.2-1 [106503] kde-i18n-3.4.0-1 -> [116284] kde-i18n-3.4.2-1 [111302] hotplug-2004_09_23-7 -> [118092] hotplug-2004_09_23-10 [112023] fedora-release-4-2 -> [113067] fedora-release-4-rawhide [108436] xterm-200-6 -> [118082] xterm-200-9 [106145] ppc64-utils-0.7-9 -> [118408] ppc64-utils-0.7-11 [104559] htdig-3.2.0b6-5 -> [117484] htdig-3.2.0b6-6 - libgal2-2.4.2-4 [110442] gaim-1.3.0-1.fc4 -> [118167] gaim-1.5.0-5.fc5 [108062] aspell-en-0.51-12 -> [114279] aspell-en-6.0-1 [108357] freeradius-1.0.2-2 -> [114495] freeradius-1.0.4-2 [110988] devhelp-0.10-1 -> [116721] devhelp-0.10-5 [106525] kdebindings-3.4.0-1 -> [116107] kdebindings-3.4.2-1 [110439] nautilus-2.10.0-4 -> [117668] nautilus-2.12.0-1 [111391] boost-1.32.0-6 -> [116965] boost-1.33.0-3 [104523] nano-1.3.5-0.20050302 -> [117495] nano-1.3.8-1 [110577] epiphany-1.6.1-3 -> [117510] epiphany-1.8.0-1 [111496] yum-2.3.2-7 -> [118230] yum-2.4.0-3 [104625] GConf-1.0.9-16 -> [115534] GConf-1.0.9-17 [105438] g-wrap-1.3.4-8 -> [113627] g-wrap-1.3.4-9 [105029] pcre-5.0-4 -> [117019] pcre-6.3-1 [103293] pychecker-0.8.14-3 -> [117907] pychecker-0.8.16-1 [107295] gnome-bluetooth-0.5.1-12 -> [116637] gnome-bluetooth-0.5.1-14 [110227] setarch-1.7-3 -> [113328] setarch-1.8-1 [107662] kdeaddons-3.4.0-2 -> [116097] kdeaddons-3.4.2-1 [105264] MyODBC-2.50.39-24 -> [116340] MyODBC-2.50.39-25 [108719] nmap-3.81-3 -> [118008] nmap-3.93-1 [107878] glib2-2.6.4-1 -> [116932] glib2-2.8.1-1 [106280] m2crypto-0.13-2 -> [117174] m2crypto-0.15-1 [105135] pango-1.8.1-2 -> [116700] pango-1.10.0-1 [106004] atk-1.9.1-1 -> [117631] atk-1.10.3-1 [110350] gtk2-2.6.7-4 -> [117200] gtk2-2.8.3-1 [110963] logwatch-6.0.1-2 -> [118256] logwatch-6.1.2-4 [107440] libxml2-2.6.19-1 -> [117989] libxml2-2.6.22-1 [107238] gnome-mag-0.12.0-2 -> [116495] gnome-mag-0.12.1-2 [109656] tzdata-2005i-2 -> [117537] tzdata-2005m-2 [105136] ddd-3.3.10-2 -> [112263] ddd-3.3.11-1 [111516] ethereal-0.10.11-2 -> [118418] ethereal-0.10.12-7 [105946] mrtg-2.11.1-3 -> [117906] mrtg-2.12.2-2 [109779] curl-7.13.1-3 -> [112559] curl-7.14.0-1 [110585] mozilla-1.7.8-2 -> [118143] mozilla-1.7.11-5 [104474] cdrdao-1.1.9-9 -> [114286] cdrdao-1.2.0-1 [111152] policycoreutils-1.23.10-2 -> [118399] policycoreutils-1.27.1-1 [108677] selinux-doc-1.19.5-1 -> [118233] selinux-doc-1.22-1 [108338] checkpolicy-1.23.1-1 -> [118421] checkpolicy-1.27.2-1 [107547] sound-juicer-2.10.1-1 -> [116671] sound-juicer-2.11.91-1 [104852] mod_auth_mysql-2.6.1-4 -> [112597] mod_auth_mysql-2.9.0-1 [106515] kdeartwork-3.4.0-1 -> [116101] kdeartwork-3.4.2-1 [111390] setools-2.1.0-5 -> [118333] setools-2.1.2-1 [111060] grub-0.95-13 -> [114871] grub-0.95-15 [110652] openssh-4.0p1-3 -> [117588] openssh-4.2p1-1 [108233] gnucash-1.8.11-3 -> [117839] gnucash-1.8.11-4 [108697] MySQL-python-1.2.0-1 -> [115666] MySQL-python-1.2.0-2 [106774] PyQt-3.14.1-1 -> [117928] PyQt-3.15-1 [106773] sip-4.2.1-1 -> [117925] sip-4.3.1-1 [109146] jpilot-0.99.8-0.pre8.4 -> [116645] jpilot-0.99.8-0.pre10.2 [108932] lftp-3.1.3-1 -> [117026] lftp-3.3.0-1 [107870] cdrtools-2.01.1-9 -> [117294] cdrtools-2.01.1-10 - apel-10.6-6 [107986] mysql-4.1.11-2 -> [116941] mysql-4.1.12-3 [108427] tmpwatch-2.9.3-1 -> [112807] tmpwatch-2.9.4-1 [107682] kdenetwork-3.4.0-3 -> [116293] kdenetwork-3.4.2-1 [111395] fedora-logos-1.1.31-1 -> [117762] fedora-logos-1.1.31-2 [100527] junit-3.8.1-3jpp_4fc -> [112932] junit-3.8.1-3jpp_5fc [105492] xmlsec1-1.2.7-4 -> [118326] xmlsec1-1.2.9-1 [104606] openCryptoki-2.1.5-9 -> [117535] openCryptoki-2.1.5-10 [110363] system-config-bind-4.0.0-16_FC4 -> [116458] system-config-bind-4.0.0-30_FC5 [110056] system-config-date-1.7.18-1 -> [115786] system-config-date-1.7.99.0-1 [109174] system-config-keyboard-1.2.6-2 -> [118188] system-config-keyboard-1.2.6-3 [109127] system-config-kickstart-2.5.22-2 -> [118045] system-config-kickstart-2.5.24-1 - system-config-mouse-1.2.11-1 [108705] system-config-netboot-0.1.14-1 -> [116895] system-config-netboot-0.1.30-1_FC5 [110270] system-config-nfs-1.3.10-1 -> [113615] system-config-nfs-1.3.11-1 [110775] system-config-printer-0.6.131-1 -> [117714] system-config-printer-0.6.142-1 [110889] system-config-securitylevel-1.5.8-1 -> [116959] system-config-securitylevel-1.6.4-1 [110271] system-config-services-0.8.25-1 -> [116537] system-config-services-0.8.26-1 [111388] system-config-soundcard-1.2.11-5 -> [116656] system-config-soundcard-1.2.12-5 [111429] system-config-display-1.0.29-1 -> [117812] system-config-display-1.0.31-1 [111664] alsa-lib-1.0.9rc4-2 -> [114503] alsa-lib-1.0.9rf-3 [105652] tcl-8.4.9-3 -> [113371] tcl-8.4.11-1 [105658] tk-8.4.9-3 -> [113372] tk-8.4.11-1 [109302] lvm2-2.01.08-2.1 -> [118142] lvm2-2.01.14-2 [110929] device-mapper-1.01.02-1.0 -> [115634] device-mapper-1.01.04-1.0 [108262] libgnomecups-0.2.0-2 -> [117671] libgnomecups-0.2.1-1 [109132] tvtime-0.9.15-7 -> [117915] tvtime-1.0.1-1 - hpijs-1.7.1-3 [111138] shared-mime-info-0.16-3 -> [112690] shared-mime-info-0.16-4 [110914] evolution-data-server-1.2.2-3 -> [118144] evolution-data-server-1.4.0-2 [106495] gnome-keyring-0.4.2-1 -> [117659] gnome-keyring-0.4.4-1 [111218] udev-058-1 -> [118405] udev-069-4 - pcmcia-cs-3.2.8-4.12 - iiimf-le-xcin-0.1.10-1 [109118] gnome-netstatus-2.10.0-4 -> [116639] gnome-netstatus-2.11.90-2 [110265] perl-XML-NamespaceSupport-1.08-7 -> [117865] perl-XML-NamespaceSupport-1.09-1 [107102] memtest86+-1.55.1-1 -> [113262] memtest86+-1.60-1 [100526] antlr-2.7.4-2jpp_1fc -> [112867] antlr-2.7.4-2jpp_2fc [111283] jakarta-commons-beanutils-1.7.0-1jpp_4fc -> [114381] jakarta-commons-beanutils-1.7.0-2jpp_2fc [111285] jakarta-commons-collections-3.1-1jpp_4fc -> [114380] jakarta-commons-collections-3.1-2jpp_2fc [101451] jakarta-commons-dbcp-1.2.1-3jpp_1fc -> [112880] jakarta-commons-dbcp-1.2.1-3jpp_2fc [111286] jakarta-commons-digester-1.6-2jpp_4fc -> [114394] jakarta-commons-digester-1.6-2jpp_6fc [111288] jakarta-commons-logging-1.0.4-2jpp_4fc -> [114180] jakarta-commons-logging-1.0.4-2jpp_6fc [111289] jakarta-commons-modeler-1.1-3jpp_4fc -> [114487] jakarta-commons-modeler-1.1-4jpp_2fc [101447] jakarta-commons-pool-1.2-2jpp_1fc -> [112885] jakarta-commons-pool-1.2-2jpp_2fc [101435] jakarta-commons-validator-1.1.3-1jpp_1fc -> [112887] jakarta-commons-validator-1.1.3-1jpp_2fc [100530] jdepend-2.6-2jpp_3fc -> [112928] jdepend-2.6-2jpp_4fc [111423] log4j-1.2.8-7jpp_4fc -> [112933] log4j-1.2.8-7jpp_5fc [96312] oro-2.0.8-1jpp_2fc -> [113162] oro-2.0.8-1jpp_3fc [109898] regexp-1.3-1jpp_5fc -> [114182] regexp-1.3-2jpp_3fc [100606] xalan-j2-2.6.0-2jpp_1fc -> [114410] xalan-j2-2.6.0-3jpp_3fc [109899] xerces-j2-2.6.2-4jpp_5fc -> [114312] xerces-j2-2.6.2-5jpp_2fc [109900] xml-commons-1.0-0.b2.6jpp_12fc -> [114196] xml-commons-1.0-0.b2.7jpp_3fc [96303] xml-commons-resolver-1.1-1jpp_4fc -> [113163] xml-commons-resolver-1.1-1jpp_5fc [101437] jakarta-commons-lang-2.0-2jpp_1fc -> [112883] jakarta-commons-lang-2.0-2jpp_2fc [96300] java_cup-0.10-0.k.1jpp_2fc -> [114395] java_cup-0.10-0.k.1jpp_5fc [100540] avalon-logkit-1.2-2jpp_4fc -> [113428] avalon-logkit-1.2-3jpp_1fc [101462] cryptix-3.2.0-4jpp_1fc -> [112869] cryptix-3.2.0-4jpp_2fc [101463] cryptix-asn1-20011119-4jpp_1fc -> [112873] cryptix-asn1-20011119-4jpp_2fc [101464] gnu.getopt-1.0.9-4jpp_1fc -> [112875] gnu.getopt-1.0.9-4jpp_2fc [110589] xorg-x11-6.8.2-31 -> [115364] xorg-x11-6.8.2-45 [108218] aspell-is-0.51.1-1 -> [114361] aspell-is-0.51.1-2 [106231] pyparted-1.6.9-3 -> [117327] pyparted-1.6.9-4 [110354] mod_auth_kerb-5.0-6 -> [118413] mod_auth_kerb-5.0-7 [106186] iprutils-2.0.13.7-2 -> [115548] iprutils-2.0.15.3-1 [110365] tomcat5-5.0.30-5jpp_6fc -> [118323] tomcat5-5.0.30-8jpp_3fc [110776] xchat-2.4.3-3 -> [118268] xchat-2.4.5-1 [111287] jakarta-commons-el-1.0-2jpp_3fc -> [114396] jakarta-commons-el-1.0-4jpp_2fc - GFS-6.1-0.pre22.6 [107882] k3b-0.11.23-3 -> [114095] k3b-0.12.2-1 [111251] hal-0.5.2-2 -> [117285] hal-0.5.4-3 [107343] gnome-volume-manager-1.3.1-1 -> [117761] gnome-volume-manager-1.5.1-1 [106242] pam_passwdqc-0.7.6-1 -> [118214] pam_passwdqc-1.0.2-1 [106603] libidn-0.5.15-1 -> [118283] libidn-0.5.19-1 [110913] evolution-connector-2.2.2-5 -> [118165] evolution-connector-2.4.0-2 [111158] selinux-policy-targeted-1.23.16-6 -> [118397] selinux-policy-targeted-1.27.1-4 [111157] selinux-policy-strict-1.23.16-6 -> [118396] selinux-policy-strict-1.27.1-4 - ecj-3.1-0.M4.9 [104920] diskdumputils-1.0.1-6 -> [116910] diskdumputils-1.1.9-2 [108918] module-init-tools-3.1-3 -> [117811] module-init-tools-3.2-0.pre7.3 [104418] numactl-0.6.4-1.18 -> [113672] numactl-0.6.4-1.23 [104522] libwmf-0.2.8.3-8 -> [115159] libwmf-0.2.8.4-1 [107934] authd-1.4.3-4.devel -> [113028] authd-1.4.3-5.devel [112018] gamin-0.1.0-1.1 -> [118342] gamin-0.1.6-2 [111127] vino-2.10.0-4 -> [117670] vino-2.12.0-1 [109620] HelixPlayer-1.0.4-4 -> [116508] HelixPlayer-1.0.5-2 [110936] totem-1.0.2-1 -> [116504] totem-1.1.4-1 - gnbd-kernel-2.6.11.2-20050420.133124.FC4.35 [108039] aspell-de-0.50-10 -> [114277] aspell-de-0.50-11 [109112] eclipse-changelog-2.0.1_fc-21 -> [114192] eclipse-changelog-2.0.1_fc-22 [111405] eclipse-cdt-3.0.0_fc-0.M6.7 -> [116981] eclipse-cdt-3.0.0_fc-1 - iiimf-le-chinput-0.3-19 [106138] synaptics-0.14.0-2 -> [115769] synaptics-0.14.3-3 [110766] libsepol-1.5.9-2 -> [118331] libsepol-1.9.4-1 [108031] aspell-af-0.50-2 -> [114179] aspell-af-0.50-4 [103800] aspell-bg-0.50-9 -> [114176] aspell-bg-0.50-11 [108032] aspell-br-0.50-2 -> [114181] aspell-br-0.50-4 [108037] aspell-cy-0.50-2 -> [114274] aspell-cy-0.50-4 [108040] aspell-el-0.50-2 -> [114278] aspell-el-0.50-4 [108043] aspell-fo-0.51-2 -> [114281] aspell-fo-0.51-4 [108045] aspell-ga-0.50-2 -> [114288] aspell-ga-0.50-4 [108047] aspell-gd-0.50-2 -> [114357] aspell-gd-0.50-4 [108048] aspell-gl-0.50-2 -> [114358] aspell-gl-0.50-4 [108049] aspell-hr-0.51-2 -> [114359] aspell-hr-0.51-4 [108050] aspell-id-0.50.1-2 -> [114360] aspell-id-0.50.1-4 [105301] busybox-1.00-4 -> [111857] busybox-1.00-5 [104570] sysfsutils-1.2.0-4 -> [113812] sysfsutils-1.3.0-1 - rgmanager-1.9.31-3 [109173] openswan-2.3.1-2 -> [118022] openswan-2.4.0-1 [110687] NetworkManager-0.4-15.cvs20050404 -> [118005] NetworkManager-0.4.1-2.cvs20050912 [112106] java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh -> [118416] java-1.4.2-gcj-compat-1.4.2.0-40jpp_51rh [106674] gnome-keyring-manager-0.0.4-3 -> [117662] gnome-keyring-manager-2.12.0-1 [105646] evolution-webcal-2.2.0-1 -> [118166] evolution-webcal-2.4.0.1-2 [106722] krb5-auth-dialog-0.2-5 -> [116572] krb5-auth-dialog-0.2-6 [107396] dhcpv6-0.10-13 -> [116466] dhcpv6-0.10-14 [106006] dasher-3.2.15-1 -> [117634] dasher-3.2.18-1 [111497] firefox-1.0.4-4 -> [118182] firefox-1.5-0.5.0.beta1 [110588] thunderbird-1.0.2-6 -> [116773] thunderbird-1.0.6-5 - valgrind-callgrind-0.9.11-1 [106256] pam_ccreds-1-6 -> [112255] pam_ccreds-1-7 [100966] createrepo-0.4.2-2 -> [114098] createrepo-0.4.3-1 [111205] audit-0.8.2-1 -> [116925] audit-1.0.3-1 [109751] kdewebdev-3.4.0-3 -> [116306] kdewebdev-3.4.2-1 [98989] slib-3a1-2 -> [117769] slib-3a1-5 [105026] webalizer-2.01_10-28 -> [118412] webalizer-2.01_10-29 [108536] ipv6calc-0.48-5 -> [118194] ipv6calc-0.50-1 [100524] classpathx-mail-1.0-3jpp_1fc -> [111780] classpathx-mail-1.0-4jpp_2fc [111648] gnu-crypto-2.0.1-1jpp_5fc -> [114171] gnu-crypto-2.0.1-1jpp_7fc [107249] OpenIPMI-1.4.11-5 -> [117704] OpenIPMI-1.4.14-9 [100864] zsh-4.2.1-2 -> [113141] zsh-4.2.5-1 [104688] sane-backends-1.0.15-9 -> [116782] sane-backends-1.0.16-1 - lvm2-cluster-2.01.09-3.0 - struts11-1.1-1jpp_7fc [107376] gkrellm-2.2.4-4 -> [117540] gkrellm-2.2.7-3 [108839] cpufreq-utils-0.2-1.1.14 -> [115418] cpufreq-utils-0.3-1.1.16 [108362] dmidecode-2.6-1.14 -> [117909] dmidecode-2.7-1.15 [109300] hardlink-1.0-1.13 -> [117099] hardlink-1.0-1.14 [111037] readahead-1.1-1.14 -> [115793] readahead-1.1-1.17 [104427] smartmontools-5.33-1.5 -> [115762] smartmontools-5.33-1.7 [108364] x86info-1.13-1.10 -> [117440] x86info-1.15-1.13 - python-twisted-1.3.0-4 [111505] evince-0.3.1-1 -> [118030] evince-0.4.0-2 [109178] gnome-doc-utils-0.2.0-2 -> [117722] gnome-doc-utils-0.4.0-1 [108845] gnome-menus-2.10.1-3 -> [117531] gnome-menus-2.12.0-1 [107103] gnome-python2-extras-2.10.0-2.1 -> [116816] gnome-python2-extras-2.11.4-9 [109933] gjdoc-0.7.4-5 -> [114163] gjdoc-0.7.5-4 [109753] kdelibs-3.4.0-6 -> [115465] kdelibs-3.4.2-1 [106258] kdeaccessibility-3.4.0-1 -> [116016] kdeaccessibility-3.4.2-1 [108603] fonts-korean-1.0.11-4 -> [116512] fonts-korean-1.0.11-6 [108601] fonts-japanese-0.20050222-3 -> [116488] fonts-japanese-0.20050222-7 [108604] fonts-chinese-2.15-2 -> [117399] fonts-chinese-3.00.pre2-1 [111507] poppler-0.3.2-1 -> [117476] poppler-0.4.2-1 [111030] eclipse-bugzilla-0.1.0_fc-16 -> [114650] eclipse-bugzilla-0.1.1_fc-5 [109095] eclipse-pydev-0.9.3_fc-7 -> [115587] eclipse-pydev-0.9.3_fc-11 [108005] sqlite-3.1.2-3 -> [117898] sqlite-3.2.5-1 [105636] python-urlgrabber-2.9.6-1 -> [118139] python-urlgrabber-2.9.6-3 [107161] cryptsetup-luks-1.0-1 -> [116857] cryptsetup-luks-1.0.1-2 [108817] jsch-0.1.18-1jpp_1fc -> [114185] jsch-0.1.18-1jpp_2fc [109747] latex2html-2002.2.1-3 -> [112874] latex2html-2002.2.1-4 [110960] openssl-0.9.7f-7 -> [116949] openssl-0.9.7f-9 - iiimf-12.2-4 [108246] kdevelop-3.2.0-2 -> [116301] kdevelop-3.2.2-1 - Canna-3.7p3-13 - VFlib2-2.25.6-28 [108287] perl-Archive-Zip-1.14-1 -> [117218] perl-Archive-Zip-1.16-1 [108275] pm-utils-0.01-1 -> [116385] pm-utils-0.04-1 [109632] foomatic-3.0.2-19 -> [118014] foomatic-3.0.2-28 [108982] perl-DateManip-5.42a-4 -> [117863] perl-DateManip-5.44-1 - perl-libxml-enno-1.02-31 [104653] s390utils-1.3.2-4 -> [112864] s390utils-1.3.2-5 [107373] m4-1.4.3-1 -> [118239] m4-1.4.3-2 [110355] ORBit2-2.12.1-3 -> [117666] ORBit2-2.12.4-1 [110242] GConf2-2.10.0-4 -> [117717] GConf2-2.12.0-1 [106017] libgnomecanvas-2.10.0-1 -> [117642] libgnomecanvas-2.12.0-1 [102603] libbonobo-2.8.1-1 -> [117820] libbonobo-2.10.1-2 [109591] gnome-vfs2-2.10.0-5 -> [117664] gnome-vfs2-2.12.0-1 [109285] libgnome-2.10.0-3 -> [117751] libgnome-2.12.0-1 [109171] libbonoboui-2.8.1-4 -> [117749] libbonoboui-2.10.1-1 [104650] librsvg2-2.9.5-2 -> [117304] librsvg2-2.11.1-1 [107485] eel2-2.10.0-2 -> [117651] eel2-2.12.0-1 [106316] tn5250-0.16.5-5 -> [113112] tn5250-0.16.5-6 [106143] yaboot-1.3.12-9 -> [118141] yaboot-1.3.13-0.16 [107969] libgnomeui-2.10.0-1 -> [117980] libgnomeui-2.12.0-2 [104629] libglade2-2.5.1-2 -> [116545] libglade2-2.5.1-3 [105166] libIDL-0.8.5-2 -> [117667] libIDL-0.8.6-1 [110521] usermode-1.80-1 -> [116503] usermode-1.81-1 [102961] docbook-style-xsl-1.68.1-1 -> [116354] docbook-style-xsl-1.69.1-1 [104584] intltool-0.33-2 -> [115810] intltool-0.34.1-1 [110237] evolution-2.2.2-5 -> [118148] evolution-2.4.0-2 [104652] xmltex-20020625-5 -> [118338] xmltex-20020625-6 [105333] pygtk2-2.6.0-2 -> [117772] pygtk2-2.8.0-1 [105908] gnome-python2-2.10.0-1 -> [116511] gnome-python2-2.11.3-2 [104649] libpng10-1.0.18-2 -> [115463] libpng10-1.0.18-3 [96234] aspell-pt-0.50-9 -> [114369] aspell-pt-0.50-10 [106303] stardict-2.4.4-3 -> [118242] stardict-2.4.5-1 [108452] glibc-kernheaders-2.4-9.1.94 -> [111898] glibc-kernheaders-2.4-9.1.95 [105250] wordtrans-1.1pre13-10 -> [115775] wordtrans-1.1pre13-11 [104417] microcode_ctl-1.11-1.21 -> [118068] microcode_ctl-1.12-1.23 [109638] gnome-pilot-2.0.13-2 -> [116547] gnome-pilot-2.0.13-7.fc5 [106005] at-spi-1.6.3-1 -> [117632] at-spi-1.6.6-1 [110915] gail-1.8.3-2 -> [117635] gail-1.8.5-1 [106768] vsftpd-2.0.3-1 -> [117823] vsftpd-2.0.3-10 [108150] authconfig-4.6.12-1 -> [117485] authconfig-5.0.1-1 [104665] linuxdoc-tools-0.9.21-5 -> [113333] linuxdoc-tools-0.9.21-6 [111809] gphoto2-2.1.5-10 -> [115052] gphoto2-2.1.6-2 [104555] xmlto-0.0.18-6 -> [116003] xmlto-0.0.18-9 - perl-Time-HiRes-1.65-1 [108948] db4-4.3.27-3 -> [118387] db4-4.3.28-2 [107533] openmotif-2.2.3-10 -> [117413] openmotif-2.2.3-11 [101890] docbook-dtds-1.0-26 -> [111825] docbook-dtds-1.0-27 [111495] firstboot-1.3.42-1 -> [118187] firstboot-1.3.47-2 [107310] cups-1.1.23-15 -> [117439] cups-1.1.23-17 [108639] postfix-2.2.2-2 -> [117702] postfix-2.2.5-1 [110444] booty-0.53-1 -> [118032] booty-0.57-1 [106326] cdicconf-0.2-11 -> [113538] cdicconf-0.2-12 [110352] libwnck-2.10.0-3 -> [117752] libwnck-2.12.0-1 [110575] crypto-utils-2.2-5 -> [111863] crypto-utils-2.2-6 [107303] perl-Compress-Zlib-1.34-2 -> [117468] perl-Compress-Zlib-1.37-1.fc5 [109590] libgtop2-2.10.1-1 -> [117665] libgtop2-2.12.0-1 [110990] yelp-2.10.0-1 -> [117757] yelp-2.12.0-1 [110693] hwdata-0.158-1 -> [117804] hwdata-0.169-1 [106407] rhnlib-1.8-6.p24.1 -> [116200] rhnlib-1.8-6.p24.11 [106361] arts-1.4.0-1 -> [115461] arts-1.4.2-1 [107873] dia-0.94-11 -> [116485] dia-0.94-13 [106665] gnome-system-monitor-2.10.0-2 -> [117663] gnome-system-monitor-2.12.0-1 [106473] pwlib-1.8.4-1 -> [117530] pwlib-1.8.7-1 [106475] openh323-1.15.3-1 -> [117538] openh323-1.15.6-1 [106477] gnomemeeting-1.2.1-1 -> [118169] gnomemeeting-1.2.2-2 [93048] fonts-KOI8-R-1.0-7 -> [113604] fonts-KOI8-R-1.0-8 [104596] patchutils-0.2.30-4 -> [114399] patchutils-0.2.31-2 [107936] man-1.5p-4 -> [111925] man-1.5p-6 [110750] elinks-0.10.3-3 -> [112404] elinks-0.10.3-3.1 [107263] netatalk-2.0.2-3 -> [114554] netatalk-2.0.3-2 [107736] netdump-0.7.7-6 -> [115481] netdump-0.7.10-4 [111279] ant-1.6.2-3jpp_8fc -> [115662] ant-1.6.2-3jpp_14fc [109158] openmotif21-2.1.30-14 -> [116779] openmotif21-2.1.30-17.1 [109640] gnutls-1.0.25-1 -> [115978] gnutls-1.2.6-1 [104487] privoxy-3.0.3-7 -> [117709] privoxy-3.0.3-9 [107117] eog-2.10.0-1 -> [117654] eog-2.12.0-1 [109172] gconf-editor-2.10.0-5 -> [117718] gconf-editor-2.12.0-1 [111105] gtk2-engines-2.6.3-2 -> [117640] gtk2-engines-2.6.5-1 [111267] gnome-desktop-2.10.0-5 -> [117723] gnome-desktop-2.12.0-1 [110510] gnome-panel-2.10.1-10 -> [118149] gnome-panel-2.12.0-2 [108570] gnome-session-2.10.0-2 -> [117729] gnome-session-2.12.0-1 [109748] gnome-terminal-2.10.0-2 -> [117730] gnome-terminal-2.12.0-1 [107500] metacity-2.10.0-1 -> [117759] metacity-2.12.0-1 [107193] valgrind-2.4.0-2 -> [117903] valgrind-3.0.1-1 [111389] vte-0.11.13-2.fc4 -> [117756] vte-0.11.15-1.fc5 [105809] ghostscript-7.07-40 -> [116480] ghostscript-8.15-0.rc4.3 [108033] file-4.13-4 -> [118257] file-4.15-3 [108940] mgetty-1.1.33-1 -> [115032] mgetty-1.1.33-3_FC5 [111301] xen-2-20050522 -> [118168] xen-3.0-0.20050912.fc5.1 [106289] libraw1394-1.1.0-3 -> [114765] libraw1394-1.2.0-1.fc5 [108526] mod_perl-2.0.0-0.rc5.3 -> [112776] mod_perl-2.0.1-1.fc5 [103976] radvd-0.7.3-1_FC4 -> [114404] radvd-0.8-2.FC5 [111033] ncpfs-2.2.4-8 -> [115462] ncpfs-2.2.4-9 [106079] prelink-0.3.4-3 -> [117615] prelink-0.3.6-1 [110767] netpbm-10.27-3 -> [116518] netpbm-10.29-1
????????????????????? ???????????????????????? &FC;??? scim-anthy-0.6.1-1.fc5 struts-1.2.4-2jpp_3fc jonas-4.3.3-1jpp_10fc nspr-4.6-4 scim-1.4.2-3 anthy-6829-3 system-config-cluster-0.9.69-1.0 axis-1.2.1-1jpp_1fc bsf-2.3.0-6jpp_2fc bsh-1.3.0-5jpp_1fc concurrent-1.3.2-2jpp_1fc dtdparser-1.21-2jpp_1fc jakarta-commons-discovery-0.3-1jpp_1fc jdom-1.0-1jpp_2fc wsdl4j-1.5.1-1jpp_1fc javacc-3.2-1jpp_3fc jakarta-commons-httpclient-3.0-0.rc2.0jpp_1fc castor-0.9.5-1jpp_1fc adaptx-0.9.6-1jpp_1fc amtu-1.0.2-1 xdoclet-1.2.2-2jpp_1fc xjavadoc-1.1-1jpp_1fc jgroups-2.2.6-1jpp_1fc hsqldb-1.80.1-1jpp_1fc jonathan-core-4.1-1jpp_4fc jonathan-jeremie-4.2-1jpp_4fc jrefactory-2.8.9-3jpp_1fc mockobjects-0.09-12jpp_2fc monolog-1.8.6-1jpp_5fc oldkilim-1.1.3-2jpp_3fc p6spy-1.3-2jpp_3fc fractal-2.2-2jpp_1fc velocity-1.4-3jpp_1fc werken.xpath-0.9.4-0.beta.9jpp_1fc gnu.regexp-1.1.4-7jpp_1fc nanoxml-2.2.3-3jpp_3fc asm-1.5.3-1jpp_1fc cairo-1.0.0-1 objectweb-anttask-1.2-1jpp_1fc objectweb-deploysched-0.2-1jpp_1fc carol-1.8.9.3-1jpp_5fc jacorb-2.2-3jpp_3fc jakarta-commons-cli-1.0-6jpp_1fc tanukiwrapper-3.1.1-4jpp_3fc tog-pegasus-2.4.1-4.FC5 joram-4.1.5-1jpp_5fc jotm-2.0.5-1jpp_3fc lucene-1.4.3-1jpp_1fc geronimo-specs-1.0-0.M2.2jpp_4fc jakarta-commons-codec-1.3-2jpp_1fc howl-logger-0.1.8-1jpp_3fc dhcdbd-1.8-1 aspell-ru-0.99f7-2 hplip-0.9.5-3 gpart-0.1h-1 iso-codes-0.47-1 gif89encoder-0.90-0.b.1jpp_1fc jonathan-rmi-3.1-5 pup-0.0.2-1 jorm-2.4.3-1jpp_2fc jorm-rdb-adapter-2.6-1jpp_1fc medor-1.4.4-1jpp_1fc medor-expression-1.4.2-1jpp_1fc perseus-cache-1.3.4-1jpp_1fc perseus-concurrency-1.4-1jpp_1fc perseus-dependency-1.4-1jpp_1fc perseus-distribution-1.3.2-1jpp_1fc perseus-fos-1.3.1-1jpp_1fc perseus-persistence-1.3.4-1jpp_1fc perseus-pool-1.3.3-1jpp_1fc systemtap-0.4.1-2 pcmciautils-007-1 scim-tables-0.5.3-4 libsemanage-1.3.2-1 scim-hangul-0.2.0-5.fc5 scim-pinyin-0.5.91-1 scim-chewing-0.2.1-1 scim-qtimm-0.9.4-1 libchewing-0.2.7-1 kasumi-0.9-3.fc5 kexec-tools-1.101-2 libsetrans-0.1.7-1 icu-3.4-4 libiec61883-1.0.0-8.fc5
????????????????????? ?????????????????????????????? ccs-0.25-0.17 cman-1.0-0.pre33.15 cman-kernel-2.6.11.5-20050601.152643.FC4.2 dlm-1.0-0.pre21.10 dlm-kernel-2.6.11.5-20050601.152643.FC4.2 fence-1.27-16 GFS-kernel-2.6.11.8-20050601.152643.FC4.2 gnbd-1.0-0.pre14.6 gulm-1.0-0.pre30.1 iddev-1.9-21 magma-1.0-0.pre21.7 magma-plugins-1.0-0.pre18.3
?????? system-config-monitor ???????????????????????????????????? synaptic ?????????????????????????????????????????????????????????????????????????????? ??????????????????????????????????????????????????????????????????????????????????????? ???????????????gnome-screensaver ??????????????? xscreensaver ????????????
--- NEW FILE package-notes-zh_CN.xml ---
??????????????????????????????????????? &DISTRO; &DISTROVER; ?????????????????????????????????????????????????????????????????????????????? Anaconda ???????????????????????????????????????????????????????????????????????? &DISTRO; &DISTROVER; ?????????
????????????????????????????????????????????????????????????
&FEX; ??????&FEX; ???????????? &FP; ???????????????????????????????????????????????????????????????????????????????????? &FC; ?????????&FEX; ????????? &FC; &LOCALVER; ???????????????????????????????????????????????????????????????????????? &FEX; ????????????http://fedoraproject.org/wiki/Extras???????????? &FEX; ????????????????????????????????? yum ????????? yum install <packagename> ?????????<packagename> ?????????????????????????????????????????????????????????????????? abiword ???????????????????????? yum install abiword ?????????????????????????????????????????????
Audit ???????????? <command>auditd</command> ??????????????????Audit ???????????? auditd ????????????????????? auditd ????????????????????? audit ??????????????? /var/log/audit/audit.log ?????????????????????????????? /etc/auditd.conf ????????????&SEL; ??? AVC ???????????? audit ????????????????????????????????? /var/log/audit/audit.log ????????? autitd ??????????????????????????? audit ??????????????? syslog?????????????????????????????? /var/log/messages ????????????????????? dmesg ???????????????Audit ??????????????????????????? PAM ?????????????????????????????????????????????????????????????????????????????? audit ???????????????????????????????????????????????????????????? audit=1 ??????????????????????????????????????????????????????????????????????????? auditctl -e 1
LinuxThreads ??? NPTL????????????????????? LinuxThreads ???????????????????????? &FC; &LOCALVER; ????????????????????????????????????????????? NPTL ????????????????????????????????????????????? &RHL; 9 ????????????????????????????????? LinuxThreads?????????????????????????????????NPTL ??????????????????????????????????????????????????? (?????? -fexception ????????????????????? C ?????????)????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ??? ?????????????????? lib{,64} ??????????????? lib64???????????????????????? DSO ???????????? lib64/ ?????????????????? &FC; &LOCALVER; ??????????????????????????? LinuxThreads ????????????????????????????????? linuxthreads-devel ?????????????????? ??????????????????????????????????????????????????????????????????????????????????????? glibc ?????????????????? libpgthread DSH?????????????????????????????????????????????????????? LD_LIBRARY_PATH=/lib{,64}/obsolete/linuxthreads ??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? DT_RPATH (??????????????? LD_LIBRARY_PATH ??????)???????????????????????????????????? LinuxThreads ?????????????????????????????????????????????????????????FC5 ???????????? LinuxThreads ?????????????????????????????????????????????????????? NPTL??????????????? NPTL ???????????????????????????
?????? <filename>slocate</filename> ??????????????? locate ???????????????????????????????????????????????????????????? locate ?????????????????? /etc/updatedb.conf ?????? DAILY_UPDATE ????????? ???
<filename>openssh</filename> ???????????????????! ??&FC; &LOCALVER; ?????? OpenSSH ?????? OpenSSH 3.9?????????????????????????????? ~/.ssh/config ???????????????????????????????????????????????????????????????????????????????????????ssh ?????????????????? ~/.ssh/config ??????????????? ~/ ????????????????????????????????? 600??? ls -l ~/.ssh/config -rw------- 1 username username 400 May 5 18:44 /home/username/.ssh/config ?????? ~/ ?????????????????????????????????????????????????????????????????? /home/username/????????????????????????????????????OpenSSH ??????????????????????????? X11 ?????????????????? X11 ????????????????????? ??? ?????????????????? ~/.ssh/config ????????? ??????????????? ????????????ssh ???????????????????????????????????? OpenSSH 3.8 ???????????????X11 ???????????????????????????????????????????????????????????????????????????X11 ??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ??????????????? ?????????????????? ~/.ssh/config ?????????! ?????????
Perl ?????????????????????????????? perl-5.8.0, perl-5.8.1 ??? perl-5.8.2 ?????????????????????????????????????????????????????????????????? perl ???????????????????????? perl ???????????????????????? &FC; &LOCALVER; ????????? perl-5.8.6 ???????????????
&SERVER-TOOLS; &JAVA-PACKAGE;
????????????????????? &DISTRO; ????????????????????????????????????
yumyum ???????????? sqllite ?????????????????????????????????????????????????????? Fedora Extras ?????????
&KERNEL; &SECURITY;
&DEVELOPMENT-TOOLS; &I18N; &PRINTING; &MULTIMEDIA; &ENTERTAINMENT; &WEB-SERVERS; &SAMBA; &XORG; &ENTERTAINMENT;
--- NEW FILE printing-zh_CN.xml --- --- NEW FILE project-overview-zh_CN.xml ---
&PROJ; ????????? &PROJ; ??????????????? Linux ??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????&PROJ; ?????????????????????????????? &DISTRO;??????????????? 2-3 ???????????????????????????????????????&RH; ???????????????????????????????????? &DISTRO; ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????? &PROJ; ????????? http://fedora.redhat.com/ ?????????????????????????????????????????????????????? fedora-list at redhat.com — ?????? &DISTRO; ?????????????????? fedora-test-list at redhat.com — ?????? &DISTRO; ?????????????????????????????? fedora-devel-list at redhat.com — ??????????????????????????????????????? fedora-docs-list at redhat.com — ???????????????????????? ????????????????????????????????????????????? <listname>-request (?????? <listname> ????????????????????????????????????)???????????? "subscribe"??? ??????????????????????????? Web ??????????????? http://www.redhat.com/mailman/listinfo/ ???????????????????????? rhl-list, rhl-beta-list, rhl-devel-list ??? rhl-docs-list?????????????????????????????? &PROJ; ??????????????? IRC (Internet Relay Chat) ?????????IRC ??????????????????????????????????????????????????? IRC??????????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????? &PROJ; ??????????????? IRC ????????????????????? freenode IRC ?????????????????????????????? irc.freenode.net ?????? IRC ????????????????????????????????????????????????????????????????????????????????? freenode ?????? (http://www.freenode.net/) ??????????????????&PROJ; ?????????????????? #fedora ??????????????? &PROJ; ????????????????????? #fedora-devel ???????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????? #fedora ?????????????????????????????????????????? (nick)????????? /join ???????????????????????????????????????????????? ?????? &RH; ?????? &PROJ; IRC ????????????????????????????????????
***** Error reading new file: [Errno 2] No such file or directory: 'RELEASE-NOTES-zh_CN.xml' --- NEW FILE samba-zh_CN.xml ---
Samba (Windows ?????????????????????) ?????????????????? Samba ??????????????????Samba ?????? Linux ????????? Microsoft Windows ????????????????????????????????? ?????? Windows ?????? (???????????? SMB ??????) ???????????? &DISTRO; &DISTROVER; ??????????????????????????????????????????????????????????????????????????????????????? ???????????????????????????????????? SMB ???????????????????????????????????????????????? ???????????????????????? WINS ??????????????? smb.conf ????????? "wins server" ????????? WINS ????????????????????? ?????????????????? ?????????????????????????????????????????????????????? ??????????????????????????????????????????????????? ??????????????????????????????????????????????????? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133478
--- NEW FILE security-zh_CN.xml ---
?????? ??????????????? &FC; ?????????????????? Pam_stack ????????????????????????????????????????????? fedora-test-list (http://www.redhat.com/mailman/listinfo/fedora-test-list
???????????? ??????????????? &FC; ?????????????????? ?????????????????????????????? /etc/pki/ ???????????????????????????????????????????????????????????????????????? OpenSSL: /usr/share/ssl/ ???????????????????????? /etc/pki/tls/ ??? /etc/pki/CA/??? Dovecot: ???????????? dovecot-openssl.cnf ??????????????????????????? /etc/pki/dovecot/???
SELinux ????????? MCS SELinux ????????????????????????????????????????????????????????????????????????????????? http://post-office.corp.redhat.com/archives/rhselinux-project/2005-June/msg00001.html
--- NEW FILE server-tools-zh_CN.xml ---
?????????????????????????????? ?????????????????? ???????????????????????? &DISTRO; &DISTROVER; ????????? ????????????????????? &FC; ?????????????????????????????????/?????????????????????????????????
<application>system-config-lvm</application> ?????? LVM ?????? system-config-lvm ???????????????????????????
--- NEW FILE splash-zh_CN.xml ---
???????????? &FC; &LOCALVER; ?????????????????? ???????????????????????? &DISTRO; &DISTROVER; ????????? &FC; ???????????????????????????????????????????????????????????? Linux ?????????&FP; ???????????????????????????????????????????????????????????? &RH; ??????????????? &FED; ??????????????? ???????????????????????????????????? ???????????????????????????????????????????????? http://fedora.redhat.com/docs/release-notes/ ?????????????????? &DISTRO; &DISTROVER; ??????????????? ??????????????????????????????????????? &FED; ???????????? — ?????????????????? ??????????????? (http://fedora.redhat.com/participate/communicate/) ?????? &FP; (http://fedora.redhat.com/participate/) ?????? &FP; (http://fedora.redhat.com/about/)
--- NEW FILE web-servers-zh_CN.xml ---
??????????????? ?????????????????? Web ??????????????????????????????
<command>httpd</command> ?????? httpd ??????????????????????????? ?????????????????? mod_cern_meta ??? mod_asis ????????? ???????????? mod_ext_filter???
--- NEW FILE xorg-zh_CN.xml ---
X ???????????? (????????????) ?????????????????? ???????????????????????? &DISTRO; &DISTROVER; ????????? ?????????????????? &DISTRO; ??? X ????????????????????????????????????
<filename>xorg-x11</filename> ?????? X.org ??? X11?????????????????????????????? &RH; ??? &FED; ???????????????????????? XFree86.org ????????? X11 ????????????????????????????????????????????????????????????????????? X ??????????????????????????? XFree86 X11: XFree86 X.org X11: Xorg X ???????????????????????? XFree86 X11: /etc/X11/XF86Config X.org X11: /etc/X11/xorg.conf X ???????????????????????? XFree86 X11: /var/log/XFree86.$DISPLAY.log X.org X11: /var/log/Xorg.$DISPLAY.log ???????????????????????? X ???????????????????????????????????????????????????????????? ???????????? &DISTRO; ???????????? X ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ????????? (??? 15 ????????????) ?????????????????? X ??????????????????????????????????????????????????????????????????????????? X ???????????????????????????????????????-misc-fixed-medium-r-normal--10-100-75-75-c-60-iso8859-1??? ????????????????????????????????? fontconfig????????????????????????????????????????????????Fontconfig ????????? Xft ??????????????????????????????????????????????????? fontconfig ????????????????????????????????????Fontconfig ?????????????????????????????????????????????Luxi Sans-10??? ??????????????????fontconfig ??? Xft ????????? X ??????????????????????????????????????? Qt 3 ??? GTK 2 ??????????????? (?????? KDE ??? GNOME ??????????????????) ????????? fontconfig ??? Xft ??????????????????????????????????????? X ???????????????????????? ?????????&FC; ???????????? fontconfig/Xft????????? XFS ????????????????????????????????????????????????????????? ?????? ?????????????????????????????????????????????????????????OpenOffice.org ???????????????????????????????????? ??? &DISTRO; &DISTROVER; ????????????????????????????????????????????????????????????????????????????????????????????????????????? X ??????????????????????????????????????? ?????? /usr/share/fonts/local ?????? (????????????????????????)??? mkdir /usr/share/fonts/local/ ??????????????????????????? /usr/share/fonts/local/ ????????????????????????????????????????????? (???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????)??? ttmkfdir -d /usr/share/fonts/local/ -o /usr/share/fonts/local/fonts.scale mkfontdir /usr/share/fonts/local/ ????????????????????? /usr/share/fonts/local/ ????????????????????????????????? X ??????????????? (xfs) ??????????????? chkfontpath --add /usr/share/fonts/local/ ??? fontconfig ??????????????????????????????????????????????????????????????????????????? /usr/share/fonts/ ?????? (???????????????????????????????????? ~/.fonts/ ???????????????????????????????????????)??? ????????????????????????????????? fc-cache ???????????????????????????????????? fc-cache <directory> (?????? <directory> ??? /usr/share/fonts/ ?????? ~/.fonts/ ?????????) ??????????????????????????????????????????????????????????????? Nautilus ????????? fonts:///???????????????????????????????????????????????? ?????? ???????????????????????? ".gz" ???????????????????????? gzip ??????????????????????????? (?????? gunzip ??????) ??????????????? fontconfig ???????????????????????? ???????????????????????? fontconfig/Xft ??????????????????????????????????????? ???????????????????????? GTK+ 1.2 ???????????????????????????????????????????????????????????????????????????????????????????????? ~/.gtkrc.mine ????????????????????? style "user-font" { fontset = "<font-specification>" } widget_class "*" style "user-font" (?????? <font-specification> ?????????????????????????????????????????? X ????????????????????????????????????????????? "-adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-*".)
From fedora-docs-commits at redhat.com Mon Oct 31 15:43:31 2005 From: fedora-docs-commits at redhat.com (Karsten Wade (kwade)) Date: Mon, 31 Oct 2005 10:43:31 -0500 Subject: docs-common/common legalnotice-content-en.xml,1.1,1.2 Message-ID: <200510311543.j9VFhVbm003707@cvs-int.fedora.redhat.com> Author: kwade Update of /cvs/docs/docs-common/common In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv3686 Modified Files: legalnotice-content-en.xml Log Message: I know of my own knowledge that Red Hat legal has approved this identical change to the Red Hat Enterprise Linux legalnotice, as evidenced by the changes to said notice in Enterprise Linux 4. I am backporting these changes to the derivative legalnotice for Fedora documentation. This change does not reduce or increase our legal obligation, afaik. This does not change the substance of this legalnotice in anyway. IANAL. Index: legalnotice-content-en.xml =================================================================== RCS file: /cvs/docs/docs-common/common/legalnotice-content-en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- legalnotice-content-en.xml 3 Jun 2005 03:43:08 -0000 1.1 +++ legalnotice-content-en.xml 31 Oct 2005 15:43:23 -0000 1.2 @@ -29,6 +29,13 @@ + &RH; and the &RH; "Shadow Man" logo are registered trademarks of + &FORMAL-RHI; in the United States and other countries. + + + + All other trademarks and copyrights referred to are the property of their respective owners. From fedora-docs-commits at redhat.com Mon Oct 31 23:18:28 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 31 Oct 2005 18:18:28 -0500 Subject: rpm-guide rpm-guide-advanced-packaging-en.xml, 1.2, 1.3 rpm-guide-creating-rpms-en.xml, 1.2, 1.3 rpm-guide-development-tools-en.xml, 1.2, 1.3 rpm-guide-extra-packaging-tools-en.xml, 1.2, 1.3 rpm-guide-intro-packaging-en.xml, 1.3, 1.4 rpm-guide-intro-rpm-en.xml, 1.2, 1.3 rpm-guide-management-software-en.xml, 1.2, 1.3 rpm-guide-online-resources-en.xml, 1.2, 1.3 rpm-guide-other-linuxes-en.xml, 1.2, 1.3 rpm-guide-other-os-en.xml, 1.2, 1.3 rpm-guide-packaging-guidelines-en.xml, 1.2, 1.3 rpm-guide-programming-c-en.xml, 1.2, 1.3 rpm-guide-programming-perl-en.xml, 1.2, 1.3 rpm-guide-programming-python-en.xml, 1.3, 1.4 rpm-guide-rpm-evolution-en.xml, 1.2, 1.3 rpm-guide-rpmbuild-en.xml, 1.2, 1.3 rpm-guide-scripting-en.xml, 1.2, 1.3 rpm-guide-specfiles-en.xml, 1.2, 1.3 rpm-guide-transactions-en.xml, 1.2, 1.3 rpm-guide-using-rpm-db-en.xml, 1.2, 1.3 rpm-guide-using-rpm-en.xml, 1.2, 1.3 Message-ID: <200510312318.j9VNISiA018987@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv18943 Modified Files: rpm-guide-advanced-packaging-en.xml rpm-guide-creating-rpms-en.xml rpm-guide-development-tools-en.xml rpm-guide-extra-packaging-tools-en.xml rpm-guide-intro-packaging-en.xml rpm-guide-intro-rpm-en.xml rpm-guide-management-software-en.xml rpm-guide-online-resources-en.xml rpm-guide-other-linuxes-en.xml rpm-guide-other-os-en.xml rpm-guide-packaging-guidelines-en.xml rpm-guide-programming-c-en.xml rpm-guide-programming-perl-en.xml rpm-guide-programming-python-en.xml rpm-guide-rpm-evolution-en.xml rpm-guide-rpmbuild-en.xml rpm-guide-scripting-en.xml rpm-guide-specfiles-en.xml rpm-guide-transactions-en.xml rpm-guide-using-rpm-db-en.xml rpm-guide-using-rpm-en.xml Log Message: - Bulk replaced product names with entities - Replaced SuSE with SUSE to match current brand name Index: rpm-guide-advanced-packaging-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-advanced-packaging-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-advanced-packaging-en.xml 26 Oct 2005 01:54:11 -0000 1.2 +++ rpm-guide-advanced-packaging-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -77,7 +77,7 @@ Chapter 6 covers more on dependencies. The Obsoletes dependencies are usually only used when a package is renamed, such as the - apache package becoming the httpd package, starting in Red Hat + apache package becoming the httpd package, starting in &RH; Linux 8.0. The httpd package obsoletes the apache package. @@ -1196,7 +1196,7 @@ Creating Relocatable Packages A relocatable package allows a user to specify where to install - the package. For example, if you build a package for Red Hat + the package. For example, if you build a package for &RH; Linux, the normal directory for binary executable programs is /usr/bin. Other versions of Linux, though, may place executable programs into /opt/bin, for example. If your package forces the @@ -1688,7 +1688,7 @@ different locations than originally planned. This is very useful when working with more than one version of Linux, or with other operating systems. For example, most Linux commands are stored in - /usr/bin, at least for Red Hat Linux. Other Linux distributions, + /usr/bin, at least for &RHL;. Other Linux distributions, or other operating systems may specify that programs added to the original set should be stored in /opt/bin and not /usr/bin, for example. Making your package relocatable helps users in these Index: rpm-guide-creating-rpms-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-creating-rpms-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-creating-rpms-en.xml 26 Oct 2005 01:54:11 -0000 1.2 +++ rpm-guide-creating-rpms-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -388,7 +388,7 @@ command (GNU C Compiler) instead. The options passed to the C compiler may differ depending on the architecture of the system. Other commands may exist but be located in different - locations. SuSE Linux, for example, puts a lot of programs in + locations. SUSE Linux, for example, puts a lot of programs in /opt. @@ -749,14 +749,14 @@ noarch - By default, Red Hat Linux systems expect RPMs to be built in the + By default, &RHL; systems expect RPMs to be built in the /usr/src/redhat directory. Note - This directory is obviously specific to Red Hat Linux. On other + This directory is obviously specific to &RHL;. On other Linux distributions, you'll likely see other directories. @@ -1629,7 +1629,7 @@ In this case, you see some file sizes and times differ. These differences can be explained by the fact that the original package - was compiled on a different system and older version of Red Hat + was compiled on a different system and older version of &RH; Linux than the version compiled locally. Index: rpm-guide-development-tools-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-development-tools-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-development-tools-en.xml 26 Oct 2005 01:54:11 -0000 1.2 +++ rpm-guide-development-tools-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -61,7 +61,7 @@ You may not have installed any of these editors, but all are - available as part of Red Hat Linux. You can install vi, emacs, + available as part of &RHL;. You can install vi, emacs, gedit, kedit, or kate from the packages that come with your Linux distribution. @@ -109,7 +109,7 @@ Integrated Development Environments for C Programming - If you want more of a graphical environment, Red Hat Linux ships + If you want more of a graphical environment, &RHL; ships with KDevelop, an IDE for C and C++ programming. @@ -126,7 +126,7 @@ The Eclipse IDE, while mostly used for Java development, has a C and C++ mode called CDT, for C/C++ Development Tools. Eclipse is - important because Red Hat provides an RPM-building plug-in to + important because &RH; provides an RPM-building plug-in to Eclipse. Index: rpm-guide-extra-packaging-tools-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-extra-packaging-tools-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-extra-packaging-tools-en.xml 26 Oct 2005 01:54:11 -0000 1.2 +++ rpm-guide-extra-packaging-tools-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -83,7 +83,7 @@ IMproved, or VIM (www.vim.org). VIM is the standard vi implementation (meaning that when you type vi at the command prompt, the program you really are running is vim) on many Linux - distributions, including Red Hat Linux. It is also freely + distributions, including &RHL;. It is also freely available for most other Unixes and even for non-Unix systems such as Microsoft Windows. @@ -118,7 +118,7 @@ The spec.vim file that provides VIM with an understanding of spec-file syntax is bundled with newer versions of VIM, or it can be downloaded from the Internet. Most RPM-based Linux - distributions, including Red Hat Linux, ship this file with VIM + distributions, including &RHL;, ship this file with VIM as part of their distribution and even automatically configure VIM to load this syntax file any time an RPM spec file is being edited. When using VIM on a system that does not automatically @@ -213,7 +213,7 @@ <your at email.address>" - The preceding format is what Red Hat's developers use for Red + The preceding format is what &RH;'s developers use for Red Hat Linux spec files and results in a %changelog entry that looks like the following, with the user name and e-mail address changed to protect the innocent: @@ -350,7 +350,7 @@ License. - Red Hat Linux includes RPMs of both GNU Emacs and XEmacs as part + &RHL; includes RPMs of both GNU Emacs and XEmacs as part of the distribution, and most other Linux distributions will include one or both as well. @@ -360,7 +360,7 @@ files that add new commands and functions. Stig Bj??rlykke has written a mode, rpm-spec-mode.el, which works with both GNU Emacs and with XEmacs to add many functions, making it easier to - use when editing RPM spec files. Red Hat Linux includes and + use when editing RPM spec files. &RHL; includes and enables this mode in both GNU Emacs and XEmacs, as do many other Linux distributions. @@ -705,14 +705,14 @@ listing what entries are valid for various fields in the RPM header, such as the Vendor and Packager fields. By default, Red Hat Linux ships with this configuration file set to validate - packages to make sure they are suitable for Red Hat Linux; if + packages to make sure they are suitable for &RHL;; if packaging for a different distribution, this file might need to be modified. Once rpmlint has been installed and configured, it can be run against RPMs. For example, rpmlint helps with creating packages, - such as tin (a popular Usenet client) for Red Hat Linux, since + such as tin (a popular Usenet client) for &RHL;, since it is not included with the distribution. After preparing a tin spec file, then building RPMs from that file, you can typically double-check them using rpmlint. @@ -986,7 +986,7 @@ This rpm2cpio command is bundled with RPM and is installed on - most RPM-based Linux distributions, including Red Hat Linux. + most RPM-based Linux distributions, including &RHL;. However, it is less useful on systems that do not come with RPM, such as Solaris. This "standard" implementation of rpm2cpio is written in C, and so must be compiled before it can be used. Index: rpm-guide-intro-packaging-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-intro-packaging-en.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- rpm-guide-intro-packaging-en.xml 26 Oct 2005 00:49:38 -0000 1.3 +++ rpm-guide-intro-packaging-en.xml 31 Oct 2005 23:18:20 -0000 1.4 @@ -400,9 +400,9 @@ Change of Name - + - RPM was originally called Red Hat Package Manager. After + RPM was originally called &RH; Package Manager. After adoption by other Linux distributions, the name has changed to simply the RPM Package Manager. The RPM initials remain the same. Index: rpm-guide-intro-rpm-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-intro-rpm-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-intro-rpm-en.xml 25 Oct 2005 00:32:57 -0000 1.2 +++ rpm-guide-intro-rpm-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -26,7 +26,7 @@ Several package managers are available for Linux to track and manipulate the applications installed on the system. The most widely used of these Linux package managers is the RPM Package Manager - (formerly the Red Hat Package Manager), or RPM for short, the + (formerly the &RH; Package Manager), or RPM for short, the subject of this book @@ -167,7 +167,7 @@ related applications, but what was really needed was installation and uninstallation on an application-by-application basis. - + In late 1993, Rik Faith, Doug Hoffman, and Kevin Martin began releasing the first public betas of the BOGUS Linux distribution. @@ -175,8 +175,8 @@ (pms) software that was used with it for installation and uninstallation of all software on an application-by-application basis. Shortly thereafter, in the - summer of 1994, the first public betas of Red Hat Commercial Linux - were released. &RH; initially used Red Hat Software Program + summer of 1994, the first public betas of &RH; Commercial Linux + were released. &RH; initially used &RH; Software Program Packages (RPP) as the basis of its Linux distribution. Like pms, RPP was a system-management tool that allowed for easy installation and uninstallation of applications. @@ -212,7 +212,7 @@ RPP-based distributions, &RH; looked closely at both their own RPP software and other software such as BOGUS's pms software. Developers at &RH;, particularly Marc Ewing and Erik - Troan, set out to develop what they initially called the Red Hat + Troan, set out to develop what they initially called the &RH; Package Manager (RPM). Based on experiences with earlier Linux packaging software and knowledge about packaging tools used on other platforms, &RH; had several design goals in mind when they @@ -528,7 +528,7 @@ The BOGUS distribution's pms packaging system introduced the use of pristine source code to prepare packages. - With Red Hat's early RPP package system and other similar early + With &RH;'s early RPP package system and other similar early efforts, software packagers would compile software manually, then run commands to produce a package of that compiled software. Any changes made to the application's original source Index: rpm-guide-management-software-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-management-software-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-management-software-en.xml 26 Oct 2005 01:54:11 -0000 1.2 +++ rpm-guide-management-software-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -56,15 +56,15 @@ As you start to search for RPM packages on the Internet, you???ll find thousands of packages available. Many of these packages are built specifically for various Linux distributions, such as - Conectiva, SuSE, Red Hat, or Mandrake. In many cases, the Linux + Conectiva, SUSE, &RH;, or Mandrake. In many cases, the Linux distribution won???t matter, but in general it's best to download - packages built for your version of Linux, such as Red Hat. + packages built for your version of Linux, such as &RH;. Note - Although the examples in this book assume Red Hat Linux as a base, + Although the examples in this book assume &RHL; as a base, just about everything applies to all versions of Linux that use the RPM system, unless noted otherwise. @@ -294,10 +294,10 @@ that 364 packages are found; there are lots of e-mail clients available for Linux! That number, however, is slightly misleading. Some of the packages found are prepared for the - distribution I am running (Red Hat Linux version 7.2), but + distribution I am running (&RHL; version 7.2), but others are not. Result #364, for example, appears to be the Polish(ed) Linux Distribution 1.0 package of sylpheed, the same - software offered to me packaged for my Red Hat Linux version 7.2 + software offered to me packaged for my &RHL; version 7.2 system in Result #2. @@ -641,7 +641,7 @@ - Edwin Chan's Red Hat RPMs + Edwin Chan's &RH; RPMs @@ -725,33 +725,33 @@ Figure 8-3: Installing RPM files with Nautilus. - When you install RPMs with Nautilus, it really runs the Red Hat + When you install RPMs with Nautilus, it really runs the &RH; Package Management tool. Note - Nautilus only supports RPM functionality starting with Red Hat + Nautilus only supports RPM functionality starting with &RH; Linux 8.0. This functionality may not be supported in other versions of Linux. - Red Hat Package Management + &RH; Package Management The redhat-config-packages application (say that three times - fast) comes new with Red Hat Linux 8.0. You can use the Python + fast) comes new with &RHL; 8.0. You can use the Python program in this package to manage the packages that come with - Red Hat Linux, using an interface that is very similar to the - Red Hat Linux installation program. This similarity may make it + &RHL;, using an interface that is very similar to the + &RHL; installation program. This similarity may make it easier for many users to manage their packages, although I found the program a bit short on explanations. To run this program, you first have to do a bit of searching to find it. It appears under the System Settings menu from the main - Red Hat Start menu under the default Bluecurve desktop. Select + &RH; Start menu under the default Bluecurve desktop. Select the Packages choice to launch this program. You can also start the program from the command line with the following command: @@ -761,7 +761,7 @@ This program takes a long time to read in all the information and start up. Once started, the interface provides the same - categories and much the same look as the Red Hat Linux + categories and much the same look as the &RHL; installer, as shown in Figure 8-4. @@ -773,7 +773,7 @@ The packages tool divides the packages into groups. Inside each group, the packages are divided into two sets: standard and - extra packages. (Red Hat places the packages into these + extra packages. (&RH; places the packages into these categories, striving to make a reasonable division among the many packages that come with Linux.) If you click the check box for a group, the tool will queue up all the standard packages @@ -1284,7 +1284,7 @@ repository. In addition, they support wild cards and directory accesses, so a command such as install ftp://ftp.redhat.com/pub/redhat/linux/updates/current/* can be - used to install all errata for the current release of Red Hat + used to install all errata for the current release of &RH; Linux. @@ -1294,7 +1294,7 @@ auto, AutoRPM consults the configuration file /etc/autorpm.conf to decide what to do. By default, /etc/autorpm.d/autorpm.conf is configured to download, but not automatically install, all - errata for the release of Red Hat Linux running on the local + errata for the release of &RHL; running on the local system. Editing this file makes it possible to use AutoRPM to download all errata ??? or errata for other Linux distributions ??? or to install errata automatically once downloaded. @@ -1337,8 +1337,8 @@ /etc/autoupdate.d/autoupdate.conf. By default, AutoUpdate provides several additional configuration files pre-defined for downloading updates for the most popular RPM-based Linux - distributions (Red Hat Linux, Mandrake Linux, Caldera/SCO - OpenLinux, and SuSE Linux). The autoupdate.conf file can be + distributions (&RHL;, Mandrake Linux, Caldera/SCO + OpenLinux, and SUSE Linux). The autoupdate.conf file can be modified to configure AutoUpdate to install software automatically. @@ -1453,31 +1453,31 @@ - The Red Hat Network and up2date + The &RHN; and up2date Some vendors of RPM-based Linux distributions also provide utilities that can help with management of the distributions - they create. Red Hat has created two complementary products, the - Red Hat Network (RHN) and up2date, which together provide much - the same functionality for managing Red Hat Linux installations + they create. &RH; has created two complementary products, the + &RHN; (RHN) and up2date, which together provide much + the same functionality for managing &RHL; installations as tools such as AutoUpdate and AutoRPM, as well as offering more advanced features. - Red Hat Network is a subscription-based service offered by Red - Hat Red Hat Network makes software available for installation + &RHN; is a subscription-based service offered by Red + Hat &RHN; makes software available for installation via the network. (A free evaluation is also available.) After - registering machines with Red Hat Network, administrators can + registering machines with &RHN;, administrators can pull updates or new software for installation to those registered machines. In addition, administrators have access to a Web-based administrative console from which they can view the systems they manage and can push software out to those systems. - Red Hat offers two tiers of access to Red Hat Network. Basic - Service subscriptions to Red Hat Network provide the ability to + &RH; offers two tiers of access to &RHN;. Basic + Service subscriptions to &RHN; provide the ability to manage single systems. Multiple machines can be subscribed by - the same administrator for Basic Service level Red Hat Network + the same administrator for Basic Service level &RHN; access, but they must all be managed independently. The administrator must push out errata to each machine separately. Workgroup Service subscriptions provide the same functionality @@ -1491,22 +1491,22 @@ administrators. - When using Red Hat Network to manage machines with Workgroup - Service subscriptions, Red Hat also offers two optional - services: Red Hat Network Proxy Server and Red Hat Network - Satellite. The Red Hat Network Proxy Server is, as its name - suggests, a proxy server for the Red Hat Network. Using it, - errata pushed out via Red Hat Network is downloaded by the + When using &RHN; to manage machines with Workgroup + Service subscriptions, &RH; also offers two optional + services: &RHN; Proxy Server and &RHN; + Satellite. The &RHN; Proxy Server is, as its name + suggests, a proxy server for the &RHN;. Using it, + errata pushed out via &RHN; is downloaded by the organization (only once) to a central server in-house. All - machines in that organization subscribed to Red Hat Network get + machines in that organization subscribed to &RHN; get their updated software from that in-house proxy server, significantly reducing the network bandwidth requirements needed to keep large organizations up to date. - In addition, the Red Hat Network Proxy Server can be used to + In addition, the &RHN; Proxy Server can be used to provide all subscribed machines with software not provided with - Red Hat Linux. Custom ???channels??? of supplemental software + &RHL;. Custom ???channels??? of supplemental software can be created on the Proxy Server, and machines can be subscribed to those channels as desired. Using this feature, different departments in the organization with different @@ -1518,38 +1518,38 @@ get only software that desktop machines need. - The Red Hat Network is normally centrally administered through - Red Hat. Machines subscribed to the Red Hat Network have a - system profile on file with Red Hat that details the system???s + The &RHN; is normally centrally administered through + &RH;. Machines subscribed to the &RHN; have a + system profile on file with &RH; that details the system???s essential configuration information (what software is installed on it, what CPU architecture it contains, and so forth) needed to determine which software errata are appropriate for that system. Similarly, the Web console through which machines - subscribed to Red Hat Network can be administered is also - located on a Red Hat server. Customers wishing to use Red Hat + subscribed to &RHN; can be administered is also + located on a &RH; server. Customers wishing to use &RH; Network services, but not wanting the dependency upon Internet - access to Red Hat, can create an in-house Red Hat Network by - using the Red Hat Network Satellite. This solution is often + access to &RH;, can create an in-house &RHN; by + using the &RHN; Satellite. This solution is often practical for customers who need to keep system information confidential or for customers whose systems are not able to access the Internet. - Red Hat provides several interfaces for administering machines - subscribed to the Red Hat Network. A Web-management console is + &RH; provides several interfaces for administering machines + subscribed to the &RHN;. A Web-management console is available at https://rhn.redhat.com/. Administrators of machines - subscribed to any level of the Red Hat Network can simply log + subscribed to any level of the &RHN; can simply log into this Web site and perform a variety of package-management operations from their Web browsers. In addition to viewing other things, administrators can see what software is currently - installed, select and install Red Hat Linux errata or new + installed, select and install &RHL; errata or new software, or schedule a time for automatic installation of Red Hat Linux errata. - When using Red Hat Network, rhnsd is a client-side daemon that + When using &RHN;, rhnsd is a client-side daemon that should be run on subscribed systems. It periodically launches a - helper utility, rhn_check, which connects to the Red Hat Network + helper utility, rhn_check, which connects to the &RHN; servers and checks for any actions (such as a scheduled installation of errata) that an administrator has selected in the Web console. If any actions have been scheduled for that @@ -1559,11 +1559,11 @@ every hour if necessary. - In addition, Red Hat provides client-side tools that can be used - in a more interactive fashion to connect to the Red Hat Network + In addition, &RH; provides client-side tools that can be used + in a more interactive fashion to connect to the &RHN; from subscribed systems. The up2date program provides a graphical and command-line tool that can be used to install - packages from Red Hat Network servers. When installing a new + packages from &RHN; servers. When installing a new package, up2date automatically installs any necessary dependencies the package requires, making it a very convenient tool for adding software to the system. up2date can also be run @@ -1721,7 +1721,7 @@ Update the list of installed packages associated with - this computer in the Red Hat Network database + this computer in the &RHN; database @@ -1810,9 +1810,9 @@ Current - The up2date command, the Red Hat Network client software, is - open-source software released by Red Hat under the terms of the - GNU GPL. Red Hat Network Proxy Server and Red Hat Network + The up2date command, the &RHN; client software, is + open-source software released by &RH; under the terms of the + GNU GPL. &RHN; Proxy Server and &RHN; Satellite, the server applications with which up2date interacts, are not freely available, open-source applications. For this reason, an effort is underway to develop servers available under @@ -1823,7 +1823,7 @@ The current server can be downloaded from http://current.tigris.org. Although not yet as functional as Red - Hat Network Proxy Server or Red Hat Network Satellite, current + Hat Network Proxy Server or &RHN; Satellite, current can already be used to create a RPM repository from which up2date-using clients can retrieve and install software. More advanced features, such as support for multiple ???channels??? @@ -1834,7 +1834,7 @@ urpmi and RpmDrake Mandrake provides a set of software similar to the combination - of up2date and Red Hat Network or current that can be used with + of up2date and &RHN; or current that can be used with the Mandrake Linux distribution. Links to the source code for the Mandrake applications can be found at www.linux-mandrake.com/cooker/urpmi.html. This suite of @@ -1893,7 +1893,7 @@ The Debian Project (www.debian.org/) is a nonprofit volunteer group that develops a Linux distribution, Debian GNU/Linux. The group uses a different package format, dpkg, which was developed - independently of and simultaneous to Red Hat???s creation of + independently of and simultaneous to &RH;???s creation of RPM. The two formats, dpkg and RPM, are very similar in terms of utility and functionality. In addition to having created a package format, the Debian Project later developed a collection @@ -1904,7 +1904,7 @@ In many respects, Debian???s implementation of apt is very - similar to the functionality provided by Red Hat???s up2date/Red + similar to the functionality provided by &RH;???s up2date/Red Hat Network products or Mandrake???s urpmi software. On Debian systems, apt is a client tool used to select and install new software packages or to update existing packages already @@ -1935,8 +1935,8 @@ necessary utilities that can be used to make any RPM repository apt-capable. By creating apt-capable servers using apt4rpm and then installing apt-rpm on the client systems, any RPM-based - distribution, such as Red Hat Linux, Mandrake Linux, Caldera/SCO - OpenLinux, or SuSE Linux, can then be easily managed using apt. + distribution, such as &RHL;, Mandrake Linux, Caldera/SCO + OpenLinux, or SUSE Linux, can then be easily managed using apt. Note @@ -1949,7 +1949,7 @@ Administrators managing multiple dispersed machines as well as those used to Debian administration often find it useful to configure their machines to use apt; its dependency tracking is - far better than any other tool, except for Red Hat???s + far better than any other tool, except for &RH;???s up2date/RHN combination. To use apt, administrators must install it on their machines and have access to an apt-capable RPM repository for the distribution they use. Several public FTP @@ -1969,7 +1969,7 @@ Once apt and libapt RPMs are installed, the sources.list file in /etc/apt needs to be modified to reference the apt-capable software site that will be used. For example, to configure a - machine to access the apt-capable Red Hat Linux 7.2 software + machine to access the apt-capable &RHL; 7.2 software distributed by the Tuxfamily.org server, the /etc/apt/sources.list file needs to list: @@ -1981,8 +1981,8 @@ os - These two lines, respectively, access the Red Hat Linux 7.2 and - Red Hat Linux 7.2 errata RPMs being served by the system + These two lines, respectively, access the &RHL; 7.2 and + &RHL; 7.2 errata RPMs being served by the system apt-rpm.tuxfamily.org. If you also want access to source RPMs, the following lines are necessary as well. @@ -2084,7 +2084,7 @@ it installs any RPM files you double-click. - Red Hat Linux 8 comes with a new package-management tool available + &RHL; 8 comes with a new package-management tool available from the System Settings menu. Be careful with this tool, though, as it automatically installs--and removes--dependent packages. @@ -2096,7 +2096,7 @@ The Debian GNU/Linux apt system provides many of the same capabilities as RPM, along with the network-updating capabilities - of up2date and the Red Hat Network. You can use special apt + of up2date and the &RHN;. You can use special apt packages that adapt apt for RPM-based Linux distributions and get the best of both the RPM system and the apt system. Index: rpm-guide-online-resources-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-online-resources-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-online-resources-en.xml 26 Oct 2005 01:54:11 -0000 1.2 +++ rpm-guide-online-resources-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -315,7 +315,7 @@ - Edwin Chan's Red Hat RPMs + Edwin Chan's &RH; RPMs Index: rpm-guide-other-linuxes-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-other-linuxes-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-other-linuxes-en.xml 26 Oct 2005 01:54:11 -0000 1.2 +++ rpm-guide-other-linuxes-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -1,7 +1,7 @@ - Using RPM on Non-Red Hat Linuxes + Using RPM on Non-&RHL;es This chapter covers: @@ -35,7 +35,7 @@ Although its name was originally the Red Hat Package Manager, RPM has been adopted by most major Linux distributions. With this - adoption, RPM has moved from its Red Hat roots, and RPM now stands + adoption, RPM has moved from its &RH; roots, and RPM now stands for the RPM Package Manager. @@ -78,7 +78,7 @@ Dealing with RPM versions - Red Hat Linux 8.0 ships with RPM version 4.1. Other + &RHL; 8.0 ships with RPM version 4.1. Other distributions of Linux ship with other versions of RPM. Thus, one of the first commands you can run on another Linux distribution is the rpm --version command, to see what RPM @@ -166,7 +166,7 @@ Start with the simple case and make certain that you haven???t failed to install a necessary RPM that provides the right dependency. In most cases, you can download a vendor-specific - package from your Linux vendor, such as www.suse.com for SuSE + package from your Linux vendor, such as www.suse.com for SUSE Linux. Most Linux vendors provide HTTP or FTP sites with a large set of packages created for their distributions. If such a distribution-specific package solves a dependency issue, this is @@ -212,7 +212,7 @@ This naming scheme of a base package and base-devel is used for - Red Hat Linux packages, but may not be used for other vendor + &RHL; packages, but may not be used for other vendor packages. In any case, you can solve this type of dependency by finding the relevant base packages that the package you are trying to install depends on. Consult the manuals that come with @@ -293,7 +293,7 @@ For example, a set of Build Root Policy (brp) helper scripts are run at the end of the %install section in an RPM. These scripts perform tasks such as compressing man pages. The Mandrake brp - scripts use bzip2 compression. Red Hat brp scripts use gzip + scripts use bzip2 compression. &RH; brp scripts use gzip compression. This is one case where rebuilding an RPM and then installing may work best. @@ -339,12 +339,12 @@ One way to help make vendor-specific packages, or to see which RPM macros are defined on a given Linux distribution, is to look for an RPM that contains the distribution-specific RPM - configuration. For example, on Red Hat Linux systems, the Red + configuration. For example, on &RHL; systems, the Red Hat RPM configuration is defined by the redhat-rpm-config package. - You can list the files in this package to see where Red Hat + You can list the files in this package to see where &RH; defines macros specific to their Linux distribution. @@ -396,7 +396,7 @@ These files, such as /usr/lib/rpm/redhat/macros, show you what is specific to a given Linux distribution. You can then look at the macros defined in these files to identify settings for a - particular distribution, in this case, Red Hat. Armed with this + particular distribution, in this case, &RH;. Armed with this knowledge, you can better create portable RPM spec files. @@ -540,7 +540,7 @@ $ more /etc/redhat-release - Red Hat Linux release 8.0 (Psyche) + &RHL; release 8.0 (Psyche) For packages, the convention is vendor-release for a package @@ -768,7 +768,7 @@ Dealing with Signatures - With SuSE Linux, or any Linux based on UnitedLinux 1.0, the + With SUSE Linux, or any Linux based on UnitedLinux 1.0, the RPM packages are signed with OpenPGP version 4, not 3, as used in RPM 4.1. This means that you must use some other, non-RPM means to extract the signatures from an RPM package, and then Index: rpm-guide-other-os-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-other-os-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-other-os-en.xml 26 Oct 2005 01:54:11 -0000 1.2 +++ rpm-guide-other-os-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -426,7 +426,7 @@ Running RPM on Windows The version of RPM for Windows requires cygwin, originally the - Cygnus port of many Unix tools to Windows. Now part of Red Hat, + Cygnus port of many Unix tools to Windows. Now part of &RH;, you can download the cygwin environment from the main cygwin site. @@ -964,7 +964,7 @@ install. - On an operating system that is based on RPM, such as Red Hat + On an operating system that is based on RPM, such as &RH; Linux, all packages (except for some bootstrapping code) are installed with RPM. That means nearly everything on the system is defined in the RPM database. The RPM database then has a @@ -1410,11 +1410,11 @@ settings. - In most cases the _topdir setting on Red Hat Linux systems map + In most cases the _topdir setting on &RHL; systems map to the /usr/src/redhat directory. Your system may not even have a /usr/src directory. Also you may not want to build RPMs in a redhat directory, which may cause confusion if you are building - on a non-Red Hat Linux system. + on a non-&RHL; system. Cross Reference Index: rpm-guide-packaging-guidelines-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-packaging-guidelines-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-packaging-guidelines-en.xml 26 Oct 2005 01:54:11 -0000 1.2 +++ rpm-guide-packaging-guidelines-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -474,7 +474,7 @@ Using tools can help speed up the RPM-making process, as well as give you a head start in learning how RPMs work. - RPM-building tools such as the Red Hat plugin for the Eclipse + RPM-building tools such as the &RH; plugin for the Eclipse Integrated Development Environment have proven really helpful. @@ -628,7 +628,7 @@ Packages are categorized into groups. These group names, while not always the best, appear in the graphical tools such as the - Red Hat package manager. If your application is a Linux shell + &RH; package manager. If your application is a Linux shell program, then users will expect to find it in the System Environment/Shells group and not the Development/Languages or System Environment/Daemons groups. This is a rather small Index: rpm-guide-programming-c-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-programming-c-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-programming-c-en.xml 26 Oct 2005 01:54:11 -0000 1.2 +++ rpm-guide-programming-c-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -108,14 +108,14 @@ At the very least, you???ll need a C compiler, gcc, and a text editor. The easiest way to get the C compiler is to install the - packages grouped under Software Development with the Red Hat + packages grouped under Software Development with the &RH; package management tool. Cross Reference - See Chapter 8 for more on the Red Hat package management tool. + See Chapter 8 for more on the &RH; package management tool. The gcc package requires a number of capabilities. Make sure you @@ -143,7 +143,7 @@ To program with the RPM library, you need to install the rpm-devel package. You must have a version of rpm-devel that - matches your version of the rpm package. If you have Red Hat + matches your version of the rpm package. If you have &RH; Linux, your installation CDs will also have the version of the RPM development package that corresponds to your system. @@ -165,7 +165,7 @@ of Linux. - The package you need is rpm-devel. If you installed Red Hat + The package you need is rpm-devel. If you installed &RH; Linux 8.0, the package is rpm-devel-4.1-1.06. This package includes header files, documentation, and libraries. Index: rpm-guide-programming-perl-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-programming-perl-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-programming-perl-en.xml 26 Oct 2005 01:54:11 -0000 1.2 +++ rpm-guide-programming-perl-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -82,12 +82,12 @@ A number of Perl RPM modules are available. No one module provides all the features you need, although with time, the Perl modules will consolidate into a few modules that most everyone uses. As of - this writing, the RPM2 module, by Chip Turner of Red Hat, provides + this writing, the RPM2 module, by Chip Turner of &RH;, provides the most recent approach to working with the RPM system from Perl. This chapter covers the RPM2 module. - Red Hat Linux 8.0 comes with a perl-RPM2 package, which you need + &RHL; 8.0 comes with a perl-RPM2 package, which you need to install to use this module. Otherwise, you can download the module from www.cpan.org. Install this module, as well as the perl module, which provides the Perl language interpreter. Once you @@ -98,11 +98,11 @@ Note - The version of the perl-RPM2 package that ships with Red Hat Linux + The version of the perl-RPM2 package that ships with &RHL; 8.0 has a bug in that it will not open package files that were - created with the version of rpm that ships with Red Hat Linux 8.0. + created with the version of rpm that ships with &RHL; 8.0. That is, the Perl module cannot read package files that ship with - Red Hat Linux. You can read older package files, though. This + &RHL;. You can read older package files, though. This problem only affects attempts to read .rpm files, not installed packages. The bug is related to reading signed packages but not having the GPG keys in the keyring. The latest version on @@ -942,7 +942,7 @@ upon. - Vendor: Red Hat, Inc., http://www.xfree86.org + Vendor: &FORMAL-RHI;, http://www.xfree86.org Size: 30552239 @@ -1057,7 +1057,7 @@ $ ./rpmdate.pl kernel - kernel-2.4.18-14 Red Hat, Inc. Sat Oct 5 12:29:58 2002 + kernel-2.4.18-14 &FORMAL-RHI; Sat Oct 5 12:29:58 2002 Index: rpm-guide-programming-python-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-programming-python-en.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- rpm-guide-programming-python-en.xml 26 Oct 2005 01:54:11 -0000 1.3 +++ rpm-guide-programming-python-en.xml 31 Oct 2005 23:18:20 -0000 1.4 @@ -82,7 +82,7 @@ *PyGTK is a binding between Python and the GTK+ toolkit used by the GNOME desktop, one of two main desktop environments for - Linux. (KDE is the other main desktop environment.) The Red Hat + Linux. (KDE is the other main desktop environment.) The &RH; redhat-config-packages program uses PyGTK and sports a very good-looking user interface. @@ -273,10 +273,10 @@ Note - The code examples in this chapter follow the Red Hat conventions + The code examples in this chapter follow the &RH; conventions for naming variables, such as ts for a transaction set. This is to make it easier to read the Python examples in the RPM sources, - along with Red Hat installer programs written in Python. + along with &RH; installer programs written in Python. You will need a transaction set in just about every Python script @@ -335,7 +335,7 @@ This example uses the rpmdb-redhat package, which holds a - database of all Red Hat Linux packages. The explicit call to + database of all &RHL; packages. The explicit call to openDB opens the RPM database. In most Python scripts, though, you do not want to call openDB. Instead, a transaction set will open the database as needed. @@ -2212,8 +2212,8 @@ You can use a check callback to automatically bring in packages that are required into a transaction set. You can - bring in packages from the Red Hat RPM database package, which - contains a database of all Red Hat packages, the rpmdb-redhat + bring in packages from the &RH; RPM database package, which + contains a database of all &RH; packages, the rpmdb-redhat package. You can open the database from this package by using the trick described previously for opening transactions to more than one RPM database at a time. Simply set the _dbpath @@ -3005,7 +3005,7 @@ Where to Go from Here The RPM bindings for Python are documented along with the C - programming API. On a Red Hat Linux system, look in the file + programming API. On a &RHL; system, look in the file /usr/share/doc/rpm-devel-4.1/apidocs/html/group__python.html to see the start of the Python-specific documentation. @@ -3025,7 +3025,7 @@ To learn more about programming in Python, install the python-docs package. The python-docs package has a large set of online documentation for Python, including the official Python Tutorial. - With Red Hat Linux, start at + With &RHL;, start at /usr/share/doc/python-docs-2.2.1/html/tut/tut.html. Index: rpm-guide-rpm-evolution-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-rpm-evolution-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-rpm-evolution-en.xml 26 Oct 2005 01:54:11 -0000 1.2 +++ rpm-guide-rpm-evolution-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -23,14 +23,14 @@ RPM 3.0.5 is the final release of the 3.x series of RPM. It was the - release of RPM shipped with Red Hat Linux 6.2 and older releases. It + release of RPM shipped with &RHL; 6.2 and older releases. It is still in wide use by other vendors as well. Cobalt???s Linux distributions use an RPM implementation version based on RPM 3.0.5, - for example. (Red Hat Linux was upgraded to RPM 4 via an errata.) + for example. (&RHL; was upgraded to RPM 4 via an errata.) - RPM 4.0.4 was used with the 7.x releases of Red Hat Linux, and RPM - 4.1 first shipped with Red Hat Linux 8.0. Packages produced + RPM 4.0.4 was used with the 7.x releases of &RHL;, and RPM + 4.1 first shipped with &RHL; 8.0. Packages produced targeting RPM 3.0.5 should work with nearly all implementations of RPM still in use today. Packages produced targeting RPM 4.0.4 or RPM 4.1 will work only with recent RPM implementations. Index: rpm-guide-rpmbuild-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-rpmbuild-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-rpmbuild-en.xml 26 Oct 2005 01:54:11 -0000 1.2 +++ rpm-guide-rpmbuild-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -360,7 +360,7 @@ cpu-vendor-os - For example, i686-redhat-linux specifies a 686 CPU with Red Hat + For example, i686-redhat-linux specifies a 686 CPU with &RH; Linux. Other CPUs include ppc for PowerPC and sparc for Sun SPARC. @@ -731,14 +731,14 @@ For example, you can use the rpm -i command to install a source RPM. This installs the sources provided by the source RPM, not the actual application. Normally, when you install a source RPM on a - Red Hat Linux system, the package gets installed into + &RHL; system, the package gets installed into /usr/src/redhat. Note - This directory is obviously specific to Red Hat Linux. On other + This directory is obviously specific to &RHL;. On other Linux distributions, you'll likely see directories such as /usr/src/OpenLinux for SCO (formerly Caldera) OpenLinux. @@ -1078,11 +1078,11 @@ Often, source RPMs are abbreviated as SRPMs. In fact, if you see a directory named SRPM or SRPMS, chances are the directory holds - source RPMs. (Red Hat uses this convention for its Linux + source RPMs. (&RH; uses this convention for its Linux distributions.) - The SRPMS directories on Red Hat CD-ROMs or on the Red Hat FTP + The SRPMS directories on &RH; CD-ROMs or on the &RH; FTP Internet site, ftp.redhat.com, indicate directories that hold source RPMs. @@ -1136,7 +1136,7 @@ compatible with the OpenPGP Internet standard as defined in RFC 2440. It started when a number of developers wanted a free implementation. One such free implementation, GPG, allows Linux - vendors such as Red Hat to include PGP in their products. So, in + vendors such as &RH; to include PGP in their products. So, in a sense, GPG provides PGP. @@ -1263,13 +1263,13 @@ Email address: please_no_spam at nospam.com - Comment: Example for Red Hat RPM Guide + Comment: Example for &RH; RPM Guide You selected this USER-ID: - "Eric Foster-Johnson (Example for Red Hat RPM Guide) + "Eric Foster-Johnson (Example for &RH; RPM Guide) <erc at no_spam.com>" @@ -1317,7 +1317,7 @@ pub 1024D/01681C24 2002-11-05 Eric Foster-Johnson (Example for - Red Hat RPM + &RH; RPM Guide) <please_no_spam at nospam.com> @@ -1585,7 +1585,7 @@ built and - signed by Red Hat, Inc. using `rpm -K' using the GNU GPG + signed by &FORMAL-RHI; using `rpm -K' using the GNU GPG package. @@ -1680,7 +1680,7 @@ This example shows an error message when trying to verify the - key. Then, after importing the Red Hat public key, the + key. Then, after importing the &RH; public key, the verification works. @@ -1716,11 +1716,11 @@ - Getting the Red Hat public key + Getting the &RH; public key - Strangely enough, the Red Hat public key is not installed when - you install Red Hat Linux 8.0. If you need the key, the Red Hat - public key is available on the root directory of all Red Hat + Strangely enough, the &RH; public key is not installed when + you install &RHL; 8.0. If you need the key, the &RH; + public key is available on the root directory of all &RH; Linux CD-ROMs, as shown in the following listing: @@ -1737,7 +1737,7 @@ Note - You can also download this key file from the Red Hat FTP site, + You can also download this key file from the &RH; FTP site, at ftp://ftp.redhat.com/pub/redhat/linux/8.0/en/os/i386/. Index: rpm-guide-scripting-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-scripting-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-scripting-en.xml 26 Oct 2005 01:54:11 -0000 1.2 +++ rpm-guide-scripting-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -925,7 +925,7 @@ Name : perl-XML-Dumper Relocations: /usr - Version : 0.4 Vendor: Red Hat, Inc. + Version : 0.4 Vendor: &FORMAL-RHI; Release : 22 Build Date: Tue 06 Aug 2002 01:53:30 PM CDT @@ -945,7 +945,7 @@ fd372689897da07a - Packager : Red Hat, Inc. + Packager : &FORMAL-RHI; <http://bugzilla.redhat.com/bugzilla> Index: rpm-guide-specfiles-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-specfiles-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-specfiles-en.xml 26 Oct 2005 01:54:11 -0000 1.2 +++ rpm-guide-specfiles-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -293,7 +293,7 @@ These directories are the default directories. See Chapter 21 for changing RPM default values. In addition, these are the - defaults for Red Hat Linux. See Chapters 19 and 20 for + defaults for &RHL;. See Chapters 19 and 20 for discussions on other versions of Linux and other non-Linux operating systems, respectively. @@ -439,13 +439,13 @@ The Distribution: directive is used by Linux distribution - vendors such as Red Hat to identify that the package is part + vendors such as &RH; to identify that the package is part of a given distribution, or was built for a particular distribution. Most packages created outside of the Linux vendors don???t provide this directive. - Distribution: Red Hat Linux + Distribution: &RHL; The Icon: directive names an icon file stored in the RPM. The @@ -2214,7 +2214,7 @@ The example directories shown above come from the standard RPM - macro file, /usr/lib/rpm/macros, instead of the Red Hat-specific + macro file, /usr/lib/rpm/macros, instead of the &RH;-specific file, /usr/lib/rpm/redhat/macros, which holds: Index: rpm-guide-transactions-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-transactions-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-transactions-en.xml 26 Oct 2005 01:54:11 -0000 1.2 +++ rpm-guide-transactions-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -360,7 +360,7 @@ can query for packages installed when you installed or upgraded your version of Linux. First, query for the transaction ID of a package you know was installed with the - Linux distribution, such as setup on a Red Hat system: + Linux distribution, such as setup on a &RH; system: $ rpm -q --qf "%-20{NAME} %-20{INSTALLTID}\n" setup @@ -450,7 +450,7 @@ This example shows just a few of the packages installed when - the Red Hat Linux was installed. + the &RHL; was installed. With these options, you can find the transaction IDs for given @@ -547,7 +547,7 @@ Note - The up2date name comes from the Red Hat service for keeping a + The up2date name comes from the &RH; service for keeping a system up to date with regard to package versions. Index: rpm-guide-using-rpm-db-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-using-rpm-db-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-using-rpm-db-en.xml 26 Oct 2005 01:54:11 -0000 1.2 +++ rpm-guide-using-rpm-db-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -481,7 +481,7 @@ - Red Hat application, usually for configuring your + &RH; application, usually for configuring your system @@ -763,7 +763,7 @@ Name : tcsh Relocations: (not relocateable) - Version : 6.10 Vendor: Red Hat, Inc. + Version : 6.10 Vendor: &FORMAL-RHI; Release : 6 Build Date: Sun 24 Jun 2001 10:45:29 @@ -785,7 +785,7 @@ Size : 764000 License: distributable - Packager : Red Hat, Inc. + Packager : &FORMAL-RHI; <http://bugzilla.redhat.com/bugzilla> @@ -1839,7 +1839,7 @@ Name : grep Relocations: /usr - Version : 2.5.1 Vendor: Red Hat, + Version : 2.5.1 Vendor: &RH;, Inc. @@ -1869,7 +1869,7 @@ Signature : DSA/SHA1, Tue 03 Sep 2002 04:17:47 PM CDT, Key ID - 219180cddb42a60ePackager : Red Hat, Inc. + 219180cddb42a60ePackager : &FORMAL-RHI; <http://bugzilla.redhat.com/bugzilla> @@ -3502,7 +3502,7 @@ If what you???ve seen so far isn???t enough, the rpm command supports a number of extra queries, mostly of use to developers - at Red Hat. + at &RH;. Table 5-7 summarizes these extra queries. Index: rpm-guide-using-rpm-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-using-rpm-en.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- rpm-guide-using-rpm-en.xml 26 Oct 2005 01:54:11 -0000 1.2 +++ rpm-guide-using-rpm-en.xml 31 Oct 2005 23:18:20 -0000 1.3 @@ -754,7 +754,7 @@ packages are obviously interrelated. From the name eruby-libs, you can guess that the package will be in a file with a name like eruby-libs-0.9.8-2.i386.rpm. (I cheated and used the - actual package on the Red Hat installation CDs.) + actual package on the &RH; installation CDs.) But you can see how the version numbers of the two files, and @@ -971,10 +971,10 @@ Note that when you purchase an upgraded version of Linux, such - as Red Hat Linux, all the packages with the product should be + as &RHL;, all the packages with the product should be properly aligned with each other as to versions. This alignment problem is an issue that the Linux vendors, such as - Red Hat, need to take care of. The main problems occur when + &RH;, need to take care of. The main problems occur when you need packages beyond those offered with your Linux distribution. @@ -1037,10 +1037,10 @@ The --aid option depends on a separate package that contains - an RPM database with all packages installed. For Red Hat + an RPM database with all packages installed. For &RH; Linux, this package is rpmdb-redhat. This separate database, built as if all packages were installed (all packages that - come with Red Hat Linux in this case), allows the rpm command + come with &RHL; in this case), allows the rpm command to search for which packages would solve dependencies. @@ -1973,7 +1973,7 @@ Separate each file name with a colon. - With Red Hat Linux, the default set of initialization files are: + With &RHL;, the default set of initialization files are: /usr/lib/rpm/rpmrc:/usr/lib/rpm/redhat/rpmrc:/etc/rpmrc:~/.rpmrc From fedora-docs-commits at redhat.com Mon Oct 31 23:24:39 2005 From: fedora-docs-commits at redhat.com (Stuart Ellis (elliss)) Date: Mon, 31 Oct 2005 18:24:39 -0500 Subject: rpm-guide rpm-guide-intro-rpm-en.xml,1.3,1.4 Message-ID: <200510312324.j9VNOdta019116@cvs-int.fedora.redhat.com> Author: elliss Update of /cvs/docs/rpm-guide In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv19069 Modified Files: rpm-guide-intro-rpm-en.xml Log Message: Don't use entities for abreviation expansions, in case the entity changes Index: rpm-guide-intro-rpm-en.xml =================================================================== RCS file: /cvs/docs/rpm-guide/rpm-guide-intro-rpm-en.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- rpm-guide-intro-rpm-en.xml 31 Oct 2005 23:18:20 -0000 1.3 +++ rpm-guide-intro-rpm-en.xml 31 Oct 2005 23:24:32 -0000 1.4 @@ -175,8 +175,8 @@ (pms) software that was used with it for installation and uninstallation of all software on an application-by-application basis. Shortly thereafter, in the - summer of 1994, the first public betas of &RH; Commercial Linux - were released. &RH; initially used &RH; Software Program + summer of 1994, the first public betas of Red Hat Commercial Linux + were released. &RH; initially used Red Hat Software Program Packages (RPP) as the basis of its Linux distribution. Like pms, RPP was a system-management tool that allowed for easy installation and uninstallation of applications. @@ -212,7 +212,7 @@ RPP-based distributions, &RH; looked closely at both their own RPP software and other software such as BOGUS's pms software. Developers at &RH;, particularly Marc Ewing and Erik - Troan, set out to develop what they initially called the &RH; + Troan, set out to develop what they initially called the Red Hat Package Manager (RPM). Based on experiences with earlier Linux packaging software and knowledge about packaging tools used on other platforms, &RH; had several design goals in mind when they