docs-commits October 2005

docs-commits@lists.fedoraproject.org

1 participants
91 discussions

docs-common/packaging fedora-doc-common.spec,NONE,1.1
by fedora-docs-commits＠redhat.com 12 Oct '05

12 Oct '05

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

1 0

docs-common Makefile,NONE,1.1
by fedora-docs-commits＠redhat.com 12 Oct '05

12 Oct '05

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 <stickster(a)gmail.com> # 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 <fedora-docs-list(a)redhat.com> - $(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}

1 0

example-tutorial Makefile,1.14,1.15
by fedora-docs-commits＠redhat.com 12 Oct '05

12 Oct '05

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}

1 0

docs-common/bin xmlformat-fdp.conf,1.5,1.6
by fedora-docs-commits＠redhat.com 11 Oct '05

11 Oct '05

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

1 0

jargon-buster jargon-buster-en.xml,1.10,1.11
by fedora-docs-commits＠redhat.com 05 Oct '05

05 Oct '05

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 @@ <!ENTITY % FEDORA-ENTITIES-EN SYSTEM "../docs-common/common/fedora-entities-en.ent"> %FEDORA-ENTITIES-EN; -<!ENTITY BOOKID "jargon-buster-1.9.3 (2005-09-07)">  +<!ENTITY BOOKID "jargon-buster-1.9.4 (2005-09-30)">  ]> @@ -180,6 +180,16 @@ </para> </revdescription> </revision> + <revision> + <revnumber>1.9.4</revnumber> + <date>30 Sep 2005</date> + <authorinitials>PaulWFrields</authorinitials> + <revdescription> + <para> + Some term fixes (#160265). + </para> + </revdescription> + </revision> </revhistory> </articleinfo> @@ -274,8 +284,8 @@ Use <application>BitTorrent</application> to download &FC; by downloading and opening a torrent file. The official &FC; torrent tracker is located at <ulink - url="http://torrent.dulug.duke.edu/"/>. 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;. </para> </glossdef> </glossentry> @@ -988,20 +998,6 @@ </para> </glossdef> </glossentry> - <glossentry id="gl-jb-redhat-config-packages"> - <glossterm>redhat-config-packages</glossterm> - <glossdef> - <para> - The <application>redhat-config-packages</application> - 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, <application>redhat-config-packages</application> - is not often used. Users should instead use the <xref - linkend="gl-jb-yum"/> utility to install new software. - </para> - </glossdef> - </glossentry> <glossentry> <glossterm>rhgb</glossterm> <glossdef> @@ -1103,6 +1099,20 @@ <glossseealso otherterm="gl-jb-rpm">RPM</glossseealso> </glossdef> </glossentry> + <glossentry id="gl-jb-system-config-packages"> + <glossterm>system-config-packages</glossterm> + <glossdef> + <para> + The <application>system-config-packages</application> + 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, <application>system-config-packages</application> + is not often used. Users should instead use the <xref + linkend="gl-jb-yum"/> utility to install new software. + </para> + </glossdef> + </glossentry> <glossentry id="gl-jb-up2date"> <glossterm>up2date</glossterm> <glossdef>

1 0

rpm-guide rpm-guide-specfiles-en.xml,NONE,1.1
by fedora-docs-commits＠redhat.com 04 Oct '05

04 Oct '05

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 ---  <chapter id="ch-specfiles"> <title>Working with Spec Files</title> <para> 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/) </para> <para/> <para> In This Chapter </para> <para> *Writing spec files </para> <para> *Defining package information </para> <para> *Controlling the build </para> <para> *Listing the files in the package </para> <para> *Defining spec file macros </para> <para> 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. </para> <para> 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. </para> <para> 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. </para> <sect1> <title>Reading Spec Files</title> <para> 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: </para> <para> *You will see that the spec file syntax is not really as complicated as it appears. </para> <para> *You will see how many others have solved problems similar to those you need to solve. </para> <para> 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. </para> <para> 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. </para> <para> 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. </para> <para> 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. </para> </sect1> <sect1> <title>Writing Spec Files</title> <para> Spec files are text files containing RPM directives. These directives use a simple syntax of a tag name, a colon, and a value: </para> <para> TagName: value </para> <para> For example: </para> <para> Version: 1.15 </para> <para> 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. </para> <para> In addition to this directive syntax, you can define macros using the RPM %define syntax. For example: </para> <para> %define major 2 </para> <para> 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: </para> <para> source: %{name}-%{version}.tar.gz </para> <para> See the section "Defining Spec File Macros" later in this chapter for more options for macros. </para> <para> Major sections in the spec file are also delimited with % markers. For example, the build section starts with %build on a line by itself. </para> <para> Note </para> <para> 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. </para> <para> Blank lines separate sections in the spec file, which makes sense for readability as well. </para> <sect2> <title>Comments</title> <para> 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. </para> <para> # This is a comment. </para> <para> 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. </para> <para> Tip </para> <para> Avoid single percent signs, %, in comments. For example: </para> <para> # Added new commands to %prep </para> <para> 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...] <para> <require name="make" /> </para> <para> </buildrequires> </para> <para/> <para>  </para> <para> <package group="System/Base" autoreqprov="no"> </para> <para> <requires> </para> <para> <require name="glibc" /> </para> <para> </requires> </para> <para> <summary>The Bash package contains the bash program.</summary> </para> <para> <description>%{summary} </para> <para> Bash is the Bourne-Again SHell, which is a widely used command interpreter </para> <para> on Unix systems. Bash is a program that reads from standard input, the </para> <para> keyboard. A user types something and the program will evaluate what he has </para> <para> typed and do something with it, like running a program.</description> </para> <para> <files list="%{name}.files.lst" /> </para> <para> </package> </para> <para/> <para> <package name="bash-doc" group="Documentation/System/Base" autoreqprov="no"> </para> <para> <requires> </para> <para> <require name="%{name}" /> </para> <para> </requires> </para> <para> <summary>Documentation for the bash package.</summary> </para> <para> <description>%{summary}</description> </para> <para> <pre script="%{name}-doc.pre.sh" /> </para> <para> <files list="%{name}-doc.files.lst" /> </para> <para> </package> </para> <para/> <para>  </para> <para> <prep script="%{name}.prep.sh"> </para> <para> <setup /> </para> <para> <script>echo &quot;Prep completed&quot;</script> </para> <para> </prep> </para> <para> <build script="%{name}.build.sh" /> </para> <para> <install script="%{name}.install.sh" /> </para> <para> <clean script="%{name}.clean.sh" /> </para> <para/> <para>  </para> <para> <changelog> </para> <para> <changes date="Mon Aug 26 2002" version="2.05a-02test" </para> <para> author="" author-email=""> </para> <para> <change>Added setup macro to extract files</change> </para> <para> <change>Initial version ready for jbj</change> </para> <para> </changes> </para> <para> </changelog> </para> <para> </spec> </para> <para> Note </para> <para> 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. </para> </sect1> <sect1> <title>Summary</title> <para> 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. </para> <para> 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. </para> <para> 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. </para> <para> 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. </para> <para> 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. </para> <para> 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. </para> <para> 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. </para> </sect1> </chapter>

1 0

rpm-guide rpm-guide-using-rpm-en.xml,NONE,1.1
by fedora-docs-commits＠redhat.com 04 Oct '05

04 Oct '05

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 ---  <chapter id="ch-using-rpm"> <title>Using RPM</title> <para> 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/) </para> <para/> <para> In This Chapter </para> <para> *Installing and upgrading software </para> <para> *Removing software </para> <para> This chapter covers the most common uses for RPM: installing, removing, and upgrading software. These are the most frequently used RPM commands. </para> <para> 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. </para> <sect1> <title>The rpm Command</title> <para> 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. </para> </sect1> <sect1> <title>Upgrading and Installing Software</title> <para> 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: </para> <para> jikes-1.16-1.i386.rpm </para> <para> 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. </para> <para> 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: </para> <para> jikes-1.16-1.src.rpm </para> <para> 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.) </para> <para> Cross Reference </para> <para> Chapters 9 and 12 cover building RPMs from source RPMs. </para> <para> The rpm command provides three main operations for upgrading and installing packages: </para> <para> 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. </para> <para> A freshen operation means to install a new version of a package only if you have already installed another version of the package. </para> <para> 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. </para> <para> The following sections cover the command-line options that apply to these operations. </para> <sect2> <title>Upgrading with the rpm command</title> <para/> <para> Almost all installation steps use the rpm command with the ��U option, short for upgrade, as introduced in Chapter 3. The basic syntax is: </para> <para> rpm -U package_name </para> <para> For example: </para> <para> rpm ��i jikes-1.16-1.i386.rpm </para> <para> You can also use the --upgrade long option in place of -U. </para> <para> 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. </para> <para> The rpm command may print out warnings, such as the one following: </para> <para> warning: pyxf86config-0.3.1-2.i386.rpm: Header V3 DSA </para> <para> signature: NOKEY, key ID 897da07a </para> <para> 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. </para> <para> Note </para> <para> 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. </para> <sect3> <title>Checking That the Package Is Installed</title> <para> 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: </para> <para> rpm ��q jikes </para> <para> When you run this command, you should see a response like the following: </para> <para> jikes-1.16-1 </para> <para> 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. </para> <para/> <para> 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. </para> <para> 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. </para> <para> The syntax for the --rcfile option is </para> <para> --rcfile filename </para> <para> You can also supply more than one file name. This syntax follows: </para> <para> --rcfile filename1:filename2:filename3 </para> <para> Separate each file name with a colon. </para> <para> With Red Hat Linux, the default set of initialization files are: </para> <para> /usr/lib/rpm/rpmrc:/usr/lib/rpm/redhat/rpmrc:/etc/rpmrc:~/.rpmrc </para> <para> Note </para> <para> The ~/.rpmrc means to look in the user's home directory for a file named .rpmrc. </para> <para> You can use the --showrc option to list all the rc settings. </para> <para> Cross Reference </para> <para> See Chapter 21 for more on the --showrc option. </para> <para> The --version option tells the rpm command to print out the version number of the command and then exit. For example: </para> <para> rpm --version </para> <para> This command prints out a version number, like the following: </para> <para> RPM version 4.1 </para> <para> 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: </para> <para> --dbpath directory_name </para> <para> The --pipe option tells the rpm command to send, or pipe, its output to another program. The syntax for this option is: </para> <para> --pipe command_to_send_out_to </para> </sect1> <sect1> <title>Summary</title> <para> This chapter covered the easy part of managing packages, the common actions of installing, removing, and upgrading software. </para> <para> 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. </para> <para> Table 4-3 summarizes the rpm command-line options for installing, removing, and upgrading packages. </para> <para> Table 4-3 Installing, Removing, and Upgrading with the rpm command </para> <informaltable frame="all"> <tgroup cols="2"> <tbody> <row> <entry> <para> Command </para> </entry> <entry> <para> Usage </para> </entry> </row> <row> <entry> <para> rpm ��i install_options package_files </para> </entry> <entry> <para> Install packages. </para> </entry> </row> <row> <entry> <para> rpm ��e remove_options packages </para> </entry> <entry> <para> Erase, remove, packages. </para> </entry> </row> <row> <entry> <para> rpm ��U install_options package_files </para> </entry> <entry> <para> Upgrade or install packages. Use this option for installations. </para> </entry> </row> <row> <entry> <para> rpm ��Uvh install_options package_files </para> </entry> <entry> <para> Upgrade or install packages with extra output. This is the recommended command to install packages. </para> </entry> </row> <row> <entry> <para> rpm ��F install_options package_files </para> </entry> <entry> <para> Freshen packages. </para> </entry> </row> </tbody> </tgroup> </informaltable> <para> 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. </para> </sect1> </chapter>

1 0

rpm-guide rpm-guide-using-rpm-db-en.xml,NONE,1.1
by fedora-docs-commits＠redhat.com 04 Oct '05

04 Oct '05

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 ---  <chapter id="ch-using-rpm-db"> <title>Using the RPM Database</title> <para> In This Chapter </para> <para> *Querying the RPM database </para> <para> *Getting information on RPM files </para> <para> * Finding out which packages own files on your system </para> <para> * Verifying installed packages </para> <para> *Backing up the RPM database </para> <para> *Repairing damaged RPM databases </para> <para> 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. </para> <para> This chapter covers querying both the RPM database and RPM package files. Both types of query are important: </para> <para> *Query the RPM database to see what is installed, or not installed, on your system. </para> <para> *Query package files to see what the files require, as well as what the files provide. </para> <para> 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. </para> <sect1> <title>Querying the RPM Database</title> <para> 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. </para> <para> 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. </para> <para> 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. </para> <sect2> <title>Querying packages</title> <para> The basic format of the rpm ��q command follows: </para> <para> rpm ��q package_name </para> <para> You need to provide the name of a package to query. For example: </para> <para> rpm -q telnet-0.17 </para> <para> This command returns the name of the package, if installed. For example: </para> <para> telnet-0.17-20 </para> <para> If the package is not installed, you��ll see a message like the following: </para> <para> package telnet-0.17 is not installed </para> <para> 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. </para> <para> For example, the following command uses just the base name of the package: </para> <para> $ rpm -q telnet </para> <para> telnet-0.17-20 </para> <para> Note </para> <para> 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. </para> <para> You can provide more than one package name; the rpm command reports on each package, as shown following. </para> <para> $ rpm -q telnet telnet-server </para> <para> telnet-0.17-20 </para> <para> telnet-server-0.17-20 </para> <para/> <para> 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. </para> </sect2> <sect2> <title>Querying everything</title> <para> 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. </para> <para> For example: </para> <para> rpm -qa </para> <para> This command returns every package installed on your system, quite a few packages. The packages are returned one per line, as shown following. </para> <para> words-2-17 </para> <para> kudzu-0.99.23-1 </para> <para> openldap-2.0.11-13 </para> <para> rpm-4.0.3-1.03 </para> <para> kernel-smp-2.4.7-10 </para> <para> quota-3.01pre9-3 </para> <para> expat-1.95.1-7 </para> <para> [...4111 lines suppressed...] </para> <para> 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. </para> <para> 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. </para> <para> The RPM database is really a number of Berkeley DB databases, each designed for a different type of query. </para> <para> 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. </para> <para/> <sect2> <title>Backing up the RPM database</title> <para> 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: </para> <para> # cd /var/lib </para> <para> # tar cvf rpmdb.tar ./rpm </para> <para> # gzip rpmdb.tar </para> <para> 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. </para> <para> Note </para> <para> Adding the z option to the tar command can create a compressed archive directly, without the need for the gzip command. </para> </sect2> <sect2> <title>Rebuilding the RPM database</title> <para> 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. </para> <para> For example: </para> <para> rpm --rebuilddb </para> <para> 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. </para> <para> Warning </para> <para> Before running this command, back up your RPM database. </para> <para> 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. </para> <para> 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. </para> </sect2> <sect2> <title>Creating a new RPM database</title> <para> 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. </para> <para> The basic syntax follows. </para> <para> rpm --initdb </para> <para> Note </para> <para> This command should not damage an existing database. </para> <para> 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. </para> <para> You can also use the --dbpath option to tell the rpm command to create an RPM database in a different directory. </para> <para> For example: </para> <para> mkdir /tmp/rpm </para> <para> rpm --initdb --dbpath /tmp/rpm </para> <para> These commands create a temporary directory and an RPM database in the /tmp/rpm directory. </para> <para> After running this command, you can examine the files created. </para> <para> # ls -l /tmp/rpm </para> <para> total 288 </para> <para> -rw-r--r-- 1 root root 8192 Oct 10 20:29 __db.001 </para> <para> -rw-r--r-- 1 root root 1310720 Oct 10 20:29 __db.002 </para> <para> -rw-r--r-- 1 root root 360448 Oct 10 20:29 __db.003 </para> <para> -rw-r--r-- 1 root root 12288 Oct 10 20:29 Packages </para> <para> This shows an empty RPM database. </para> </sect2> </sect1> <sect1> <title>Summary</title> <para> 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. </para> <para> 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. </para> <para> You can also use the --rebuilddb option to the rpm command to rebuild a damaged RPM database. </para> </sect1> </chapter>

1 0

rpm-guide rpm-guide-transactions-en.xml,NONE,1.1
by fedora-docs-commits＠redhat.com 04 Oct '05

04 Oct '05

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 ---  <chapter id="ch-transactions"> <title>Transactions</title> <para> In This Chapter </para> <para> *Understanding transactions </para> <para> *Querying for packages based on transactions </para> <para> *Rolling back transactions </para> <para> *Saving old packages when upgrading </para> <para> 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. </para> <para> 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. </para> <sect1> <title>Understanding Transactions</title> <para> 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. </para> <para> Transactions are common when working with databases, but they are just as important when working with packages. </para> <para> 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. </para> <sect2> <title>When do you need transactions?</title> <para> 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. </para> <para> Note </para> <para> Rollbacks work only for package upgrades with the 4.1 version of the RPM system, not package installs </para> <para> 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. </para> <para> 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. </para> <para> Use a transaction when you need to be sure that a set of packages install properly. </para> </sect2> <sect2> <title>Backing out of transactions</title> <para> 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. </para> <para> 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. </para> </sect2> </sect1> <sect1> <title>Transactions with the rpm Command</title> <para> 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: </para> <para> rpm -ihv package1.rpm package2.rpm package3.rpm </para> <para> 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. </para> <para> 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. </para> <para> 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. </para> <para> Cross Reference </para> <para> The gnorpm command is covered in Chapter 8. The rpmrebuild package is covered in the "Saving Old Packages" section in this chapter. </para> <para> You can install these packages with a transaction by using the following command: </para> <para> # rpm -ihv gnorpm-0.9-1.i386.rpm rpmrebuild-1.0-0.noarch.rpm </para> <para> Preparing... ########################################### [100%] </para> <para> package gnorpm-0.9-1 is already installed </para> <para> 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. </para> <para> 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: </para> <para> # rpm -q rpmrebuild </para> <para> package rpmrebuild is not installed </para> <para> 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: </para> <para> # rpm -i --test rpmrebuild-1.0-0.noarch.rpm </para> <para> # </para> <para> 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. </para> <para> 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. </para> <para> 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: </para> <para> # rpm -e setup jikes-1.17 </para> <para> error: Failed dependencies: </para> <para> setup is needed by (installed) basesystem-8.0-1 </para> <para> setup >= 2.0.3 is needed by (installed) initscripts-6.95-1 </para> <para> setup >= 2.5.4-1 is needed by (installed) filesystem-2.1.6-5 </para> <para> setup is needed by (installed) xinetd-2.3.7-2 </para> <para> setup is needed by (installed) dump-0.4b28-4 </para> <para> 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: </para> <para> # rpm -q jikes </para> <para> jikes-1.17-1 </para> <para> This package was not removed because it appeared as part of the same command that failed, so none of the operations were performed. </para> <para> When upgrading, you will also see an error message if any of the package upgrades fail. For example: </para> <para> # rpm -Uhv jikes-1.14-1.i386.rpm autoupdate-3.1.5-1.noarch.rpm </para> <para> error: jikes-1.14-1.i386.rpm cannot be installed </para> <para> You can then check that the jikes package, in this example, was not downgraded to the earlier version with the rpm ��q command: </para> <para> # rpm -q jikes </para> <para> jikes-1.17-1 </para> <sect2> <title>Transaction IDs</title> <para> 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. </para> <para> Note </para> <para> The fact that a transaction ID uses a Unix timestamp may change in the future. </para> <para> 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. </para> <para> 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. </para> <sect3> <title>Viewing RPM Transaction IDs</title> <para> To view the install transaction ID (a date code) for a given package, you can use a command like the following: </para> <para> $ rpm -q --qf "%-20{NAME} %-20{INSTALLTID}\n" jikes </para> <para> jikes 1035589778 </para> <para> 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. </para> <para> Cross Reference </para> <para> Chapter 5 describes the --queryformat option. </para> <para> 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: </para> <para> $ rpm -qa --qf "%-20{NAME} %-20{REMOVETID}\n" termcap </para> <para> termcap (none) </para> </sect3> <sect3> <title>Viewing the Packages Associated with a Transaction ID</title> <para> 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: </para> <para> $ rpm -q --tid 1035589778 </para> <para> jikes-1.17-1 </para> <para> 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. </para> <para> 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: </para> <para> $ rpm -q --qf "%-20{NAME} %-20{INSTALLTID}\n" setup </para> <para> setup 1033838323 </para> <para> Second, use this transaction ID and query for all packages with this ID, using code like the following: </para> <para> $ rpm -q --tid 1033838323 | more </para> <para> redhat-menus-0.26-1 </para> <para> glibc-2.2.93-5 </para> <para> cracklib-2.7-18 </para> <para> gdbm-1.8.0-18 </para> <para> gmp-4.1-4 </para> <para> libacl-2.0.11-2 </para> <para> libjpeg-6b-21 </para> <para> linc-0.5.2-2 </para> <para> pcre-3.9-5 </para> <para> shadow-utils-20000902-12 </para> <para> libtermcap-2.0.8-31 </para> <para> freetype-2.1.2-7 </para> <para> info-4.2-5 </para> <para> fileutils-4.1.9-11 </para> <para> psmisc-20.2-6 </para> <para> ntp-4.1.1a-9 </para> <para> mount-2.11r-10 </para> <para> cracklib-dicts-2.7-18 </para> <para> krb5-libs-1.2.5-6 </para> <para> cyrus-sasl-2.1.7-2 </para> <para> usermode-1.63-1 </para> <para> Xft-2.0-1 </para> <para> Note </para> <para> Be sure to replace the transaction ID shown here with the transaction ID obtained by querying your system. </para> <para> This example shows just a few of the packages installed when the Red Hat Linux was installed. </para> <para> 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. </para> </sect3> </sect2> <sect2> <title>Rolling Back Transactions</title> <para> The --rollback option to the rpm command allows you to roll back upgrades based on a time. Use a command like the following: </para> <para> # rpm ��U --rollback "3 months ago" </para> <para/> <para> 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. </para> <para> 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. </para> <para> Warning </para> <para> Before running the --rollback option, backup your RPM database as described in Chapter 5. </para> <para> 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. </para> <para> In many cases, this manual approach is safest, and you will have a clearer understanding about what was installed or upgraded on your system. </para> </sect2> </sect1> <sect1> <title>Saving Old Packages</title> <para> 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. </para> <para> Warning </para> <para> 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. </para> <para/> <para> 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. </para> <para> 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. </para> <para> Note </para> <para> The up2date name comes from the Red Hat service for keeping a system up to date with regard to package versions. </para> <para> 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. </para> <para> First, check the version you have. For example: </para> <para> # rpm -q jikes </para> <para> jikes-1.14-1 </para> <para> 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: </para> <para> # rpm -Uhv --repackage jikes-1.17-glibc2.2-1.i386.rpm </para> <para> Preparing... ########################################### [100%] </para> <para> Repackaging... </para> <para> 1:jikes ########################################### [100%] </para> <para> Upgrading... </para> <para> 1:jikes ########################################### [100%] </para> <para> This upgrade has kept a copy of the old package in the /var/spool/repackage directory. You can verify this with the following command: </para> <para> $ ls -l /var/spool/repackage/ </para> <para> total 692 </para> <para> -rw-r--r-- 1 root root 703037 Oct 25 18:49 jikes-1.14-1.i386.rpm </para> <para> You can see a version of the old package, with the old version number. </para> <para> Warning </para> <para> This is not the same as the original package. This is not a complete package. </para> <para> 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. </para> <para> 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. </para> <para> 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. </para> <para> Download rpmrebuild from http://rpmrebuild.sourceforge.net/. </para> </sect1> <sect1> <title>Summary</title> <para> 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. </para> <para> 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. </para> <para> 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. </para> <para> 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. </para> <para/> </sect1> </chapter>

1 0

rpm-guide rpm-guide-specfile-syntax-en.xml,NONE,1.1
by fedora-docs-commits＠redhat.com 04 Oct '05

04 Oct '05

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 ---  <chapter id="ch-specfile-syntax"> <title>Spec File Syntax</title> <para> In This Appendix </para> <para> *The package information tags </para> <para> *Build sections </para> <para> 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. </para> <para> The following sections summarize the spec file syntax. </para> <sect1> <title>Package Information Tags</title> <para> 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. </para> <para> 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. </para> <para> Name: name </para> <para> # Epoch: 1 </para> <para> Version: version_number </para> <para> Release: package_release_number </para> <para> 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. </para> <para> Epoch: 42 </para> <para> A number of tags allow you to define who made the package and under what conditions has the package been released: </para> <para> Vendor: name_of_vendor </para> <para> URL: URL_to_package_home </para> <para> Copyright: package_copyright_message </para> <para> Distribution: Linux_or_product_distribution </para> <para> Packager: John Q. Smith <john.smith(a)somecompany.yow> </para> <para> Group: group_for_categorizing_package </para> <para> Use the Group tag to help users categorize your package. </para> <para> The Icon tag allows you to provide a desktop icon for the package: </para> <para> Icon: filename.xpm </para> <para> A one-line summary is essential to tell users what your package is for: </para> <para> Summary: one_line_description_of_package </para> <para> You should also include a longer description section, marked by %description: </para> <para> %description </para> <para> Tcsh is an enhanced but completely compatible version of csh, the C </para> <para> shell. Tcsh is a command language interpreter which can be used both </para> <para> as an interactive login shell and as a shell script command processor. </para> <para> Tcsh includes a command line editor, programmable word completion, </para> <para> spelling correction, a history mechanism, job control and a C language </para> <para> like syntax. </para> <para> In the description section, blank lines indicate paragraphs. Lines that start with a space are not formatted. </para> <sect2> <title>Comments</title> <para> 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. </para> <para> # This is a comment. </para> <para> In spec files, comments are used mostly to help explain your syntax choices to yourself should you view the spec file later. </para> <para> Note </para> <para> Avoid percent signs, %, in comments, which may get interpreted as RPM macros. See Chapter 10 for details. </para> </sect2> <sect2> <title>Build settings</title> <para> 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. </para> <para> The BuildPreReq tag lists any prerequisites for building. For example: </para> <para> BuildPreReq: ncurses-devel </para> <para> The Buildroot tag names the temporary directory in which to build the package. For example: </para> <para> Buildroot: %{_tmppath}/%{name}-root </para> </sect2> <sect2> <title>Dependency tags</title> <para> Dependency tags define all the dependencies for the package, as described in Chapter 6. </para> <para> For each dependency, you can specify a capability name alone. For example: </para> <para> Provides: capability_name </para> <para> 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: </para> <para> Requires: capability_name >= version_number </para> <para> Requires: capability_name <= version_number </para> <para> Requires: capability_name > version_number </para> <para> Requires: capability_name < version_number </para> <para> Requires: capability_name == version_number </para> <para> Requires: capability_name = version_number </para> <para> 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: </para> <para> Requires: python >= 1.3, perl </para> <para> For add-on modules for interpreters, especially Perl, you can use the following syntax to define capabilities: </para> <para> Provides: perl(MIME-Base64) </para> <para> This example provides the MIME-Base64 add-on Perl module. </para> <para> You can also use or to specify more than one possibility. For example: </para> <para> perl(IO-Wrap) == 4.5 or perl(IO-Wrap)-4.5 </para> <para> The Provides, Requires, Obsoletes, and Conflicts dependency tags all work the same for capability names and version numbers. </para> <para> Note </para> <para> 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. </para> </sect2> <sect2> <title>Source files</title> <para> 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. </para> <para> If you have more than one of a particular kind of tag, append a number. For example: </para> <para> Source0: ftp://ftp.uk.linux.org/pub/linux/telnet-%{telnet_version}.tar.gz </para> <para> Source2: telnet-client.tar.gz </para> <para> Source3: telnet-xinetd </para> <para> Source4: telnet.wmconfig </para> <para> Patch1: telnet-client-cvs.patch </para> <para> Patch5: telnetd-0.17.diff </para> <para> Patch6: telnet-0.17-env.patch </para> <para> Patch7: telnet-0.17-issue.patch </para> <para> Patch8: telnet-0.17-sa-01-49.patch </para> <para> Patch9: telnet-0.17-env-5x.patch </para> <para> Patch10: telnet-0.17-pek.patch </para> </sect2> </sect1> <sect1> <title>Macros</title> <para> You can define macros in your spec files to help control how the package gets built. The following section describes these macros. </para> <sect2> <title>Variable definition macros</title> <para> 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: </para> <para> %define_bindir/bin </para> <para> This allows you to change the setting in one place, which is very handy for directory paths used throughout your spec files. </para> <para> Cross Reference </para> <para> See the section on Defining Macros in Spec Files in Chapter 21 for more on this subject. </para> <para> You can use this syntax for other things that may commonly change, such as version numbers. For example: </para> <para> %define major 2 </para> <para> %define minor 2 </para> <para> %define patchlevel 7 </para> <para> Version: %{major}.%{minor}.%{patchlevel} </para> <para> Table B-1 lists more special macros used within spec files. </para> <para> Table B-1 Special spec file macros </para> <informaltable frame="all"> <tgroup cols="2"> <tbody> <row> <entry> <para> Macro </para> </entry> <entry> <para> Usage </para> </entry> </row> <row> <entry> <para> %dump </para> </entry> <entry> <para> Prints out macro values </para> </entry> </row> <row> <entry> <para> %{echo:message} </para> </entry> <entry> <para> Prints message to stderr </para> </entry> </row> <row> <entry> <para> %{error:message} </para> </entry> <entry> <para> Prints message to stderr and returns BADSPEC </para> </entry> </row> <row> <entry> <para> %{expand:expression} </para> </entry> <entry> <para> Like eval, expands expression </para> </entry> </row> <row> <entry> <para> %{F:file_exp} </para> </entry> <entry> <para> Expands file_exp to a file name </para> </entry> </row> <row> <entry> <para> %global name value </para> </entry> <entry> <para> Defines a global macro </para> </entry> </row> <row> <entry> <para> %{P:patch_exp} </para> </entry> <entry> <para> Expands patch_exp to a patch file name </para> </entry> </row> <row> <entry> <para> %{S:source_exp} </para> </entry> <entry> <para> Expands source_exp to a source file name </para> </entry> </row> <row> <entry> <para> %trace </para> </entry> <entry> <para> Toggles the printing of debugging information </para> </entry> </row> <row> <entry> <para> %{uncompress:filename} </para> </entry> <entry> <para> 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. </para> </entry> </row> <row> <entry> <para> %undefine macro </para> </entry> <entry> <para> Undefines the given macro </para> </entry> </row> <row> <entry> <para> %{warn:message} </para> </entry> <entry> <para> Prints message to stderr </para> </entry> </row> </tbody> </tgroup> </informaltable> </sect2> <sect2> <title>Conditional macros</title> <para> You can use a special syntax to test for the existence of macros. For example: </para> <para> %{?macro_to_test: expression} </para> <para> 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: </para> <para> %{!?macro_to_test: expression} </para> <para> In this example, if the macro_to_test macro does not exist, then expand the expression. </para> <para> The %if macro performs an if test much like scripting languages. For example: </para> <para> %if %{old_5x} </para> <para> %define b5x 1 </para> <para> %undefine b6x </para> <para> %endif </para> <para> A %else allows you to specify what to do if the test is not successful. For example: </para> <para> %if %{old_5x} </para> <para> %define b5x 1 </para> <para> %undefine b6x </para> <para> %else </para> <para> %define b6x 1 </para> <para> %undefine b5x </para> <para> %endif </para> <para> Again, use an exclamation point to negate the test. For example: </para> <para> %if ! %{old_5x} </para> <para> %define b5x 1 </para> <para> %undefine b6x </para> <para> %endif </para> <para> You can use a && for an and test. For example: </para> <para> %if %{old_5x} && %{old_6x} </para> <para> %{error: You cannot build for .5x and .6x at the same time} </para> <para> %quit </para> <para> %endif </para> </sect2> <sect2> <title>Built-in macros</title> <para> The following macros are built into RPM and can help allow you to place your files in the right locations: </para> <para> %_prefix /usr </para> <para> %_exec_prefix %{_prefix} </para> <para> %_bindir %{_exec_prefix}/bin </para> <para> %_sbindir %{_exec_prefix}/sbin </para> <para> %_libexecdir %{_exec_prefix}/libexec </para> <para> %_datadir %{_prefix}/share </para> <para> %_sysconfdir %{_prefix}/etc </para> <para> %_sharedstatedir %{_prefix}/com </para> <para> %_localstatedir %{_prefix}/var </para> <para> %_libdir %{_exec_prefix}/lib </para> <para> %_includedir %{_prefix}/include </para> <para> %_oldincludedir /usr/include </para> <para> %_infodir %{_prefix}/info </para> <para> %_mandir %{_prefix}/man </para> </sect2> </sect1> <sect1> <title>Build Sections</title> <para> After providing information about the package, you need to define the build stages, as described in Chapters 10 and 12. </para> <sect2> <title>Build preparation</title> <para> The build preparation section sets the stage for the build. Usually this section has a %setup command. For example: </para> <para> %prep </para> <para> %setup -q </para> </sect2> <sect2> <title>Build</title> <para> 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: </para> <para> %build </para> <para> %configure </para> <para> make </para> </sect2> <sect2> <title>Installation</title> <para> After building, the installation section holds the commands to install the library or application. For example: </para> <para> %install </para> <para> rm -rf %{buildroot} </para> <para> %makeinstall </para> </sect2> <sect2> <title>Clean up</title> <para> The clean up section usually calls the make clean command to clean up the built files. For example: </para> <para> %clean </para> <para> rm -rf %{buildroot} </para> </sect2> <sect2> <title>Install and uninstall scripts</title> <para> 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: </para> <para> %post </para> <para> /sbin/chkconfig --add ypbind </para> <para/> <para> %preun </para> <para> if [ "$1" = 0 ] ; then </para> <para> /sbin/service ypbind stop > /dev/null 2>&1 </para> <para> /sbin/chkconfig --del ypbind </para> <para> fi </para> <para> exit 0 </para> <para/> <para> %postun </para> <para> if [ "$1" -ge 1 ]; then </para> <para> /sbin/service ypbind condrestart > /dev/null 2>&1 </para> <para> fi </para> <para> exit 0 </para> </sect2> </sect1> <sect1> <title>File Tags</title> <para> The %files tag lists the files your package should install. For example: </para> <para> %files </para> <para> %defattr(-,root,root) </para> <para> /usr/X11R6/bin/xtoolwait </para> <para> /usr/X11R6/man/man1/xtoolwait.* </para> <para> You should mark configuration and documentation files with %config and %doc, respectively. For example: </para> <para> %files </para> <para> %defattr(-,root,root) </para> <para> /sbin/ypbind </para> <para> %{_mandir}/*/* </para> <para> %config /etc/rc.d/init.d/* </para> <para> %config /etc/yp.conf </para> <para> %dir /var/yp </para> <para> %dir /var/yp/binding </para> <para> %doc README NEWS </para> <sect2> <title>Making relocatable packages</title> <para> You can make a relocatable package by setting up one or more Prefix tags. For example: </para> <para> Prefix: /usr </para> <para> Prefix: /etc </para> <para> 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: </para> <para> # rpm --relocate /etc=/usr/etc file_name.rpm </para> </sect2> </sect1> <sect1> <title>The Change Log</title> <para> The change log usually appears at the end of a spec file. It holds messages for each significant change. For example: </para> <para> %changelog </para> <para> * Fri Jun 21 2002 Bob Marley <marley(a)redhat.com> </para> <para> - automated rebuild </para> <para/> <para> * Tue May 08 2001 Peter Tosh <tosh(a)redhat.com> 1.3-1 </para> <para> - updated to 1.3 </para> </sect1> </chapter>

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

docs-commits October 2005