Edition 18.0.1
Abstract
Mono-spaced Bold
To see the contents of the filemy_next_bestselling_novel
in your current working directory, enter thecat my_next_bestselling_novel
command at the shell prompt and press Enter to execute the command.
Press Enter to execute the command.Press Ctrl+Alt+F2 to switch to a virtual terminal.
mono-spaced bold
. For example:
File-related classes includefilesystem
for file systems,file
for files, anddir
for directories. Each class has its own associated set of permissions.
Choose Mouse Preferences. In the Buttons tab, select the Left-handed mouse check box and click to switch the primary mouse button from the left to the right (making the mouse suitable for use in the left hand).→ → from the main menu bar to launchTo insert a special character into a gedit file, choose → → from the main menu bar. Next, choose → from the Character Map menu bar, type the name of the character in the Search field and click . The character you sought will be highlighted in the Character Table. Double-click this highlighted character to place it in the Text to copy field and then click the button. Now switch back to your document and choose → from the gedit menu bar.
Mono-spaced Bold Italic
or Proportional Bold Italic
To connect to a remote machine using ssh, typessh username@domain.name
at a shell prompt. If the remote machine isexample.com
and your username on that machine is john, typessh john@example.com
.Themount -o remount file-system
command remounts the named file system. For example, to remount the/home
file system, the command ismount -o remount /home
.To see the version of a currently installed package, use therpm -q package
command. It will return a result as follows:package-version-release
.
Publican is a DocBook publishing system.
mono-spaced roman
and presented thus:
books Desktop documentation drafts mss photos stuff svn books_tests Desktop1 downloads images notes scripts svgs
mono-spaced roman
but add syntax highlighting as follows:
package org.jboss.book.jca.ex1;
import javax.naming.InitialContext;
public class ExClient
{
public static void main(String args[])
throws Exception
{
InitialContext iniCtx = new InitialContext();
Object ref = iniCtx.lookup("EchoBean");
EchoHome home = (EchoHome) ref;
Echo echo = home.create();
System.out.println("Created Echo");
System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
}
}
Note
Important
Warning
Fedora Documentation
and the component packager-guide
. The following link automatically loads this information for you: http://bugzilla.redhat.com/.
Summary
field.
Description
field and give us the details of the error or suggestion as specifically as you can. If possible, include some surrounding text so we know where the error occurs or the suggestion fits.
Document URL: Section number and name: Error or suggestion: Additional information:
Table 1.1. Package Architecture
Platform | Architecture |
---|---|
Intel x86 or compatible | i386, i686 |
AMD64 / Intel 64 | x86_64 |
Intel Itanium | ia64 |
IBM POWER | ppc64 |
IBM System z | s390x, s390 |
No architecture | noarch |
noarch
in the architecture part of the file name, provides programs that are not dependent on any platform. Programs 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, thus are also distributed in the form of platform-independent packages.
.src.rpm
, for example:
rpm2cpio package | cpio -id
rpm2cpio eject-2.1.5-0.1.fc18.x86_64.rpm | cpio -id
rpm -qd package
rpm -qd package
command is used to get a list of included documentation files, which are defined by the %doc
directive.
rpm -qc package
rpm -qc package
command is used to get a list of included configuration files, which are defined by the %config
directive.
rpm -q --scripts package
rpm -q --scripts package
command is used to get a list of scripts, which are defined by the %pre
, %post
, %preun
, and %postun
directives.
Procedure 2.1. Creating a non-root buildroot
yum install -y rpmdevtools
~/rpmbuild/
directory where packages are built:
rpmdev-setuptree
Procedure 2.2. Creating an example package: eject
rpmdev-newspec
command, run the following commands:
cd ~/rpmbuild/SPECS
rpmdev-newspec eject
eject.spec
in the ~/rpmbuild/SPECS
directory.
/etc/rpmdevtools/
directory, which includes spec file templates called spectemplate-type.spec
. For example, to create a new spec file for a Python module, run the following commands:
cd ~/rpmbuild/SPECS
rpmdev-newspec python-antigravity
rpmdev-newspec
, run the rpmdev-newspec --help
command.
cd ~/rpmbuild/SPECS
vi eject.spec
Name: eject Version: Release: 1%{?dist} Summary: Group: License: URL: Source0: BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildRequires: Requires: %description %prep %setup -q %build %configure make %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root,-) %doc %changelog
The Group and BuildRoot tags are deprecated
Group
and BuildRoot
tags are included in the spec file templates, RPM in Fedora 18 does not require the presence of these tags in the spec file and ignores them.
The %clean and %defattr directives are deprecated
%clean
and %defattr
directives are included in the spec file templates, RPM in Fedora 18 does not require the presence of these directives in the spec file and ignores them.
Release
tag to set the release value of the package. For example, set the value to 1%{?dist}
if you are creating the initial release of the package:
Release: 1%{?dist}
{?dist}
tag is used to mark the distribution revision of a package.
Version: 2.1.5 Release: 1%{?dist} Summary: A program that ejects removable media using software control
License
tag, fill in the appropriate license for the software. In this case, eject uses the GNU General Public License v2.0 or later. The short name for this license is GPLv2+:
License: GPLv2+
URL
tag:
URL: http://www.pobox.com/~tranter
Source
tag, fill in the URL of the source archive for the package:
Source0: http://www.ibiblio.org/pub/Linux/utils/disk-management/%{name}-%{version}.tar.gz
BuildRequires
tag with requirements that are needed to build the package. BuildRequires
can contain either a list of required packages or files. For example, the eject package requires the gettext and libtool packages:
BuildRequires: gettext BuildRequires: libtool
Requires
tag. Requires
can contain either a list of required packages or files.
Requires
tag, so do not include the tag in the spec file.
%description
should be at most 79 characters long:
%description The eject program allows the user to eject removable media (typically CD-ROMs, floppy disks or Iomega Jaz or Zip disks) using software control. Eject can also control some multi-disk CD changers and even some devices' auto-eject features. Install eject if you'd like to eject removable media using software control.
%check
section between the sections %build
and %install
in the spec file. The %check
section typically contains the make test
or make check
command that runs any self-tests distributed with the software:
%check make check
%install
section by adding the following installation instructions that are specific to eject the to the spec file:
install -m 755 -d $RPM_BUILD_ROOT/%{_sbindir} ln -s ../bin/eject $RPM_BUILD_ROOT/%{_sbindir}
%find_lang
, which will locate all of the translation files that belong to the package, and put this list in a file called %{name}.lang
.
%find_lang
macro, add the following to the %install
section:
%find_lang %{name}
%{name}.lang
file with a list of translation files, add the file name with the -f
option to %files
:
%files -f %{name}.lang
%doc
directive:
%doc README TODO COPYING ChangeLog
%changelog
to describe the last change you have made to the package. Fill it in with the date, your name and email address, the version and release of the package, and a short description of what has changed in the package in the following format:
* date Packager's Name <packager's_email> version-revision - Summary of changes
rpmdev-bumpspec --comment=summary of changes --userstring=Packager's Name <packager's_email> spec file
rpmdev-bumpspec
command with the following options:
rpmdev-bumpspec --comment="Initial RPM release" --userstring="John Doe <jdoe@example.com>" eject.spec
%changelog * Wed Oct 20 2011 John Doe <jdoe@example.com> 2.1.5-0.1 - Initial RPM release
Name: eject Version: 2.1.5 Release: 1%{?dist} Summary: A program that ejects removable media using software control License: GPLv2+ URL: http://www.pobox.com/~tranter Source0: http://www.ibiblio.org/pub/Linux/utils/disk-management/%{name}-%{version}.tar.gz BuildRequires: gettext BuildRequires: libtool %description The eject program allows the user to eject removable media (typically CD-ROMs, floppy disks or Iomega Jaz or Zip disks) using software control. Eject can also control some multi-disk CD changers and even some devices' auto-eject features. Install eject if you'd like to eject removable media using software control. %prep %setup -q -n %build %configure make %{?_smp_mflags} %check make check %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT install -m 755 -d $RPM_BUILD_ROOT/%{_sbindir} ln -s ../bin/eject $RPM_BUILD_ROOT/%{_sbindir} %find_lang %{name} %files -f %{name}.lang %doc README TODO COPYING ChangeLog %{_bindir}/* %{_sbindir}/* %{_mandir}/man1/* %changelog * Wed Oct 20 2011 John Doe <jdoe@example.com> 0.8.18.1-0.1 - Initial RPM release
rpmbuild
command.
Run rpmbuild as a non-root user
rpmbuild
command as a non-root, normal, user. If you build a package as the root user, possible mistakes in the spec file, for example in the %install
section, can cause damage to your system.
Procedure 2.3. Building an example package: eject
~/rpmbuild/SOURCES/
directory.
~/rpmbuild/SPECS/
directory.
~/rpmbuild/SPECS/
directory and run the rpmbuild
command:
cd ~/rpmbuild/SPECS
rpmbuild -ba eject.spec
error: Failed build dependencies: libtool is needed by eject-2.1.5-0.1.x86_64
yum install -y libtool
%install
section, you may want to skip earlier stages of the build process with the --short-circuit
option and restart the build process at the %install
stage:
rpmbuild -bi --short-circuit eject.spec
rpmbuild
output will be as follows:
+ exit 0
rpmbuild -ba eject.spec
command, the binary package will be placed in a subdirectory of the ~/rpmbuild/RPMS/
directory and the source package will be placed in ~/rpmbuild/SRPMS/
.
.src.rpm
), run the following command:
rpmbuild -bs eject.spec
~/rpmbuild/SRPMS/
directory, or recreate it if it has been previously created.
Procedure 2.4. Testing a spec file with rpmlint
yum install -y rpmlint
rpmlint package.spec
-i
option, which provides more information on each error:
rpmlint -i package.spec
Procedure 2.5. Testing a spec file, binary, and source package with rpmlint
~/rpmbuild/SPECS/
directory in the buildroot environment and run the following command:
rpmlint package.spec ../RPMS/*/package*.rpm ../SRPMS/package*.rpm
~/rpmbuild/RPMS/architecture/
directory to locate the binary packages that were built with rpmlint.
rpmls
command:
rpmls *.rpm
rpm -ivp package.rpm
rpm -e package.rpm
Procedure 2.6. Testing a package with Mock
mock
group:
usermod -a G mock user_name && newgrp mock
rpmbuild -bs package.spec
mock -r config_name rebuild path_to_source_package
/etc/mock/
directory for a list of available configuration files.
mock -r epel-6-x86_64 ~/rpmbuild/SRPMS/eject-2.1.5-0.1.fc18.src.rpm
%
marker. For example, the build section starts with %build
.
TagName: value
Version: 1.15
version
, Version
, or VERSION
all set the same value. This syntax works for most settings, including Name
, Release
, and so on.
%global
syntax. For example:
%global major 2
major
with a value of 2
.
%{macro_name}
or just %macro_name
. For example:
source: %{name}-%{version}.tar.gz
#
character at the start of the line. That way, the line will be ignored by RPM.
%%
) as in the following example:
# %%configure
Summary: A program that ejects removable media using software control Name: eject Version: 2.1.5 Release: 11%{dist} License: GPL Source: http://metalab.unc.edu/pub/Linux/utils/disk-management/%{name}-%{version}.tar.gz Source1: eject.pam Patch1: eject-2.1.1-verbose.patch Patch2: eject-timeout.patch Patch3: eject-2.1.5-opendevice.patch Patch4: eject-2.1.5-spaces.patch Patch5: eject-2.1.5-lock.patch Patch6: eject-2.1.5-umount.patch URL: http://www.pobox.com/~tranter ExcludeArch: s390 s390x BuildRequires: gettext BuildRequires: automake BuildRequires: autoconf BuildRequires: libtool %description The eject program allows the user to eject removable media (typically CD-ROMs, floppy disks or Iomega Jaz or Zip disks) using software control. Eject can also control some multi-disk CD changers and even some devices' auto-eject features. Install eject if you'd like to eject removable media using software control. %prep %setup -q -n %{name} %patch1 -p1 -b .verbose %patch2 -p1 -b .timeout %patch3 -p0 -b .opendevice %patch4 -p0 -b .spaces %patch5 -p0 -b .lock %patch6 -p1 -b .umount %build %configure make %install rm -rf %{buildroot} make DESTDIR=%{buildroot} install # pam stuff install -m 755 -d %{buildroot}/%{_sysconfdir}/pam.d install -m 644 %{SOURCE1} %{buildroot}/%{_sysconfdir}/pam.d/%{name} install -m 755 -d %{buildroot}/%{_sysconfdir}/security/console.apps/ echo "FALLBACK=true" > %{buildroot}/%{_sysconfdir}/security/console.apps/%{name} install -m 755 -d %{buildroot}/%{_sbindir} pushd %{buildroot}/%{_bindir} mv eject ../sbin ln -s consolehelper eject popd %find_lang %{name} %files -f %{name}.lang %doc README TODO COPYING ChangeLog %attr(644,root,root) %{_sysconfdir}/security/console.apps/* %attr(644,root,root) %{_sysconfdir}/pam.d/* %{_bindir}/* %{_sbindir}/* %{_mandir}/man1/* %changelog * Wed Apr 02 2008 Zdenek Prikryl <zprikryl at, redhat.com> 2.1.5-11 - Added check if device is hotpluggable - Resolves #438610
Name: name
Name:
tag defines the (base) name of the package. This name must follow the Fedora Package Naming Guidelines. Also, this name should match the spec file name. In many cases, the name will be in all lower case. For example:
Name: eject
%{name}
. That way, if the name changes, the new name will be used by those other locations.
Version: version
Version
tag defines the upstream version number. If the version is non-numeric (that is it contains tags that are not numbers or digits), you may need to include the additional non-numeric characters in the Release
tag. If upstream uses full dates to distinguish versions, consider using version numbers of the form yy.mm[.dd]
(so a 2008-05-01
release becomes 8.05
). See Fedora Package Naming Guidelines for more information. An example of the Version
tag:
Version: 2.1.5
Release: release
Release
tag defines the value of the package's version. The initial release will typically be defined as 1%{?dist}
. After the initial release, increment the number every time a new package is released for the same version of software. If a new version of the packaged software is released, the Version
tag should be changed to reflect the new software version, and the Release
tag should be reset to 1
. See Fedora Package Naming Guidelines for more information. Refer to the Fedora Dist Tag Guidelines for a description of the dist
tag, which is not required but can be useful. An example of the Release
tag:
Release: 11%{dist}
Summary: summary
Summary
tag defines a brief, one-line summary of the package. Do not use a period at the end of the summary. For example:
Summary: A program that ejects removable media using software control
Group: group
Group
tag defines a package group, which the package is a part of. The tag must define a previously existing group, for example Applications/Engineering
. To display a complete list of existing groups, run the following command:
less /usr/share/doc/rpm-*/GROUPS
Documentation
. An example of the Group
tag:
Group: System Environment/Base
The Group tag is deprecated
Group
tag in the spec file. If the tag is defined, it will be ignored. The package groups of the yum application are used on a Fedora 18 system as the relevant source of information on which group is the package a part of.
License: license
License
tag defines the license of the packaged software. Use a standard abbreviation, for example GPLv2+
. The definition of the license should be specific; for example do not use GPL
or GPLv2
when the license is in fact GPL version 2 or greater, that is GPLv2+
. You can list multiple licenses in the tag by combining them with words and
and or
, for example GPLv2 and BSD
. Refer to the Fedora Licensing Document and the Licensing Guidelines for more information on this topic.
Copyright
in place of the License
tag. An example of the License
tag:
License: GPL
URL: URL
URL
tag defines the URL with more information about the program, for example the project website. This tag does not define where the original source code came from, use the the tag Source
for that purpose. An example of the URL
tag:
URL: http://www.pobox.com/~tranter
Source0: URL
Source
tag defines a URL for the compressed archive containing the (original) unmodified source code, as upstream released it. The tag Source
is the same as the tag Source0
. Because a full URL should be provided with this tag, its basename can be then used when looking in the SOURCES/
directory. If possible, add %{name}
and %{version}
to the URL.
Source
and the tag URL
are used for different purposes. Typically, they are both URLs, but the URL
tag points to the project website, while the Source
tag points to the actual file containing the source code.
wget -N URL
curl -R URL
Source1
, Source2
, and so on. If you are adding whole new files in addition to the unmodified sources, you can list each of them as sources as well, but list them after the unmodified sources. Remember to include a copy of each of these sources in any source package you create. For information on exceptions to this rule, such as when using revision control system, upstream using prohibited code, and so on, refer to the Fedora Source URL Guidelines. An example of the Source
tag:
Source1: eject.pam
Patch0: file_name
Patch0:
tag defines the name of the first patch that you will apply to the source code. If you need to patch the files after they have been uncompressed, edit the files, save their differences as a patch file in the ~/rpmbuild/SOURCES/
directory. Patches should make only one logical change, so it is likely to have multiple patch files. If there is more than one source, name them Patch1
, Patch2
, and so on. An example of the Patch1
tag:
Patch1: eject-2.1.1-verbose.patch
BuildArch: architecture
BuildArch
tag is used to define the build architecture of the package. If you are packaging files that are architecture-independent, for example shell scripts, data files, and so on, use BuildArch: noarch
. In this case, the architecture for the binary RPM will be noarch
. An example of the BuildArch
tag:
BuildArch: noarch
ExcludeArch: architecture
ExcludeArch
tag defines any excluded build architecture. If the package does not successfully compile, build or work on an architecture, then the architecture should be defined in the ExcludeArch
tag. An example of the ExcludeArch
tag:
ExcludeArch: i386
BuildRoot: build root
BuildRoot
defines the location of the files installed during the %install
process, which happens after the %build
compilation process. In a typical situation, leave this line alone: under the usual Fedora 18 setup, a macro that will create a new special subdirectory in the /var/tmp/
directory will be used. Newer versions of RPM ignore this value, and instead place the build root in %{_topdir}/BUILDROOT/
. An example of the BuildRoot
tag:
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
The BuildRoot tag is deprecated
BuildRoot
tag in the spec file. If the tag is defined, it will be ignored. The provided buildroot will automatically be cleaned before commands in %install
are called.
BuildRequires: requirements
BuildRequires
tag defines a comma-separated list of packages required for building (or compiling) the software. These are not automatically determined, so you must include every package needed to build the software.
ocaml >= 3.08
BuildRequires
tag:
BuildRequires: gettext
Requires: requirements
Requires
tag defines a comma-separate list of packages that are required when the software is installed. Remember that the list of packages for the Requires
tag and the BuildRequires
tag are independent: a package may be in one list but not the other, or it can be in both. The dependencies of binary packages are in many cases automatically detected by pmbuild, so it is often the case that you do not need to specify the Requires
tag at all. But if you want to highlight some specific packages as being required, or require a package that RPM cannot detect should be required, then add it to the Requires
tag. An example of the Requires
tag:
Requires: gettext
%description description text
%description
directive defines a longer, multiline description of the package. All lines must be 80 characters long or less. Blank lines are assumed to separate paragraphs. Remember that some graphical user interface installation programs will reformat paragraphs. Lines that start with whitespace, such as a space or tab, will be treated as preformatted text and displayed as is, normally with a fixed-width font. An example of the %description
directive:
%description The eject program allows the user to eject removable media (typically CD-ROMs, floppy disks or Iomega Jaz or Zip disks) using software control. Eject can also control some multi-disk CD changers and even some devices' auto-eject features. Install eject if you'd like to eject removable media using software control.
%prep
%prep
directive defines script commands to prepare the software before the start of the building process. In a typical situation, the definition is similar to %setup -q
. For example, if the source file unpacks into name
, the definition is %setup -q -n name
.
An example of the %prep
directive:
%prep %setup -q -n %{name} %patch1 -p1 -b .verbose
%build
%build
directive defines script commands to build (compile) the software, that is, to get it ready for installing.
An example of the %build directive:
%build %configure make
%check
%check
directive defines script commands to self-test the program. The self-tests are run after %build
and before %install
, so the %check
directive should be placed accordingly between the directives mentioned above. Usually, the %check
directive contains the make test
or make check
commands. These commands are separated from the %build
directive so that users can skip the self-test process, if they desire.
%check make check
%install
%install
directive defines script commands to install the software. The script commands copy the build files from the build directory %{_builddir}
(usually a subdirectory of the directory ~/rpmbuild/BUILD/
) into the build root directory %{buildroot}
(usually a subdirectory of the directory /var/tmp/
).
An example of the%install
directive:
%install rm -rf %{buildroot} make DESTDIR=%{buildroot} install install -m 755 -d %{buildroot}/%{_sysconfdir}/pam.d install -m 644 %{SOURCE1} %{buildroot}/%{_sysconfdir}/pam.d/%{name} install -m 755 -d %{buildroot}/%{_sysconfdir}/security/console.apps/ echo "FALLBACK=true" > %{buildroot}/%{_sysconfdir}/security/console.apps/%{name} install -m 755 -d %{buildroot}/%{_sbindir} pushd %{buildroot}/%{_bindir} mv eject ../sbin ln -s consolehelper eject popd
%clean
%clean
directive defines instructions on how to clean out the build root. For example:
%clean rm -rf %{buildroot}
The %clean directive is deprecated
%clean
directive in the spec file. If the tag is defined, it will be ignored.
%files
%files
directive contains a list of files in the package to be installed.
For example:
%files -f %{name}.lang
%changelog
%changelog
directive defines changes in the package.
For example:
%changelog * Wed Apr 02 2008 John Due <jdoe at example.com> 2.1.5-11 - Added check if device is hotpluggable - Resolves #438610
Revision History | |||
---|---|---|---|
Revision 0-0 | Thu Aug 25 2011 | ||
|