Differences

This shows you the differences between two versions of the page.

--- rpm [2012/04/12 18:35]
k2patel [RPM Spec File Information]
+++ rpm [2020/08/10 02:35]
@@ Line 1: / Line 1: @@
-====== RPM ======
-Package management system few tips / trick to build / modify / work with packages. \\
-Many hints information taken from original site [[http://rpm.org/ | RPM]]
-==== How to Print .spec file from RPM ====
-<code bash>
-rpm --scripts -qp <rpmfile>
-</code>
-==== First RPM ====
-Name of Package : libtorrent\\
-Building it in folder "/usr/local/src/libtorrent"\\
-<code bash>
-mkdir /usr/local/src/libtorrent
-cd /usr/local/src/libtorrent
-mkdir BUILD RPMS SOURCES SPECS SRPMS
-</code>
-Creating macro not bad idea.
-<code bash | /usr/local/src/libtorrent/.rpmmacros>
-%packager Ketan Patel
-</code>
-Get Sources from [[http://libtorrent.rakshasa.no/ | libtorrent]]\\
-Place it in "/usr/local/src/libtorrent/SOURCES"\\
-I have used following method.
-<code bash>
-cd /usr/local/src/libtorrent/SOURCES
-svn co svn://rakshasa.no/libtorrent/trunk/libtorrent libtorrent
-tar -cvf /usr/local/src/libtorrent/SOURCES/libtorrent.tar.gz libtorrent
-</code>
-Considering building rtorrent at non standard location.
-NOTE : **Please make sure code below has some SUSE Based Customization**
-<code bash | /usr/local/src/libtorrent/SPECS/libtorrent.spec>
-%define name libtorrent
-%define srcdir /usr/local/src
-%define _topdir %{srcdir}/libtorrent
-summary: rTorrent
-name: libtorrent
-Source: libtorrent.tar.gz
-License: GPL
-version: 1
-release: 1
-Group: System/Utils
-Prefix: /opt/libtorrent
-buildarch: x86_64
-BuildRoot: %{prefix}/%{name}-%{version}-%{release}-%{buildarch}-root
-%define lib %{prefix}/lib64
-%define include %{prefix}/include
-Provides: libtorrent
-Requires: ncurses, libcppunit-devel
-AutoReqProv: no
-%description
-libtorrent is a BitTorrent client for ncurses, using
-the libtorrent library. The client and library is
-written in C++ with emphasis on speed and efficiency, while delivering
-equivalent features to those found in GUI based clients in an ncurses
-client.
-%prep
-%setup -q -n libtorrent
-%build
-chmod 755 autogen.sh
-./autogen.sh
-%{suse_update_config -f}
-autoreconf -fiv
-./configure --prefix=%{prefix} --libdir=%{lib}
-make prefix=$RPM_BUILD_ROOT
-%install
-rm -rf %{buildroot}
-make DESTDIR=$RPM_BUILD_ROOT install
-rm -rf $RPM_BUILD_ROOT/%{prefix}/usr
-%clean
-make clean
-rm -rf %{buildroot}
-%files
-%defattr(-,root,root,-)
-%doc README
-/opt/libtorrent/lib64/*
-/opt/libtorrent/include/*
-%post
-echo "/opt/libtorrent/lib64/" > /etc/ld.so.conf.d/libtorrent.conf
-ldconfig
-%postun
-rm -rf %{prefix}
-rm /etc/ld.so.conf.d/libtorrent.conf
-ldconfig
-%Changelog
-* Mon Nov 08 2010 Seriously, Check release son!!
-Initial Build
-</code>
-== Building Actual RPM ==
-<code bash>
-cd /usr/local/src/libtorrent
-</code>
-<code bash>
-rpmbuild -v -bb --clean SPECS/libtorrent.spec
-</code>
-OR
-<code bash>
-rpmbuild -ba SPECS/libtorrent.spec
-</code>
-== Test Your RPM ==
-<code bash>
-rpm -Vp RPMS/x86_64/libtorrent-1-1.x86_64.rpm
-</code>
-==== Sample RPM ====
-<code bash | sample.spec>
-Name:      xgauguin-support
-Summary:   xGauguin support metapackage
-Version:   20110513
-Release:   1.blip
-Vendor:    lithiumfox
-License:   none
-Group:     Applications
-URL:       http://lithiumfox.com
-BuildRoot: %{_tmppath}/%{name}-%{version}-%(id -u -n)
-BuildArch: noarch
-Requires:  nginx, perl(Image::Size), perl(Params::Validate), perl(DateTime::Locale), perl(Class::Load), perl(parent), perl(DateTime::TimeZone), perl(Class::Singleton), perl(Test::Exception), perl(DateTime), perl(Image::Magick), perl(GD), perl(LWP), ImageMagick, gd, yum-utils
-%description
-Gauguin supporting packages
-%install
-[ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot}
-%{__mkdir_p} %{buildroot}%{_localstatedir}/www/releases
-%{__mkdir_p} %{buildroot}%{_localstatedir}/tmp/cache
-%pretrans
-## Force installation of conflicts
-# libxml2.i386, perl-Locale-Codes
-if $( ! rpm -q libxml2.i386 > /dev/null 2>&1)
-  then
-    yumdownloader libxml2.i386 > /dev/null 2>&1
-    %{__rm} /var/lib/rpm/__db.000 > /dev/null 2>&1
-    rpm --force -ivh libxml2*.rpm
-    %{__rm} libxml2*.rpm > /dev/null 2>&1
-fi
-if $( ! rpm -q perl-Locale-Codes > /dev/null 2>&1)
-  then
-    set -m
-    yumdownloader perl-Locale-Codes > /dev/null 2>&1
-    %{__rm} /var/lib/rpm/__db.000 > /dev/null 2>&1
-    rpm --force -ivh perl-Locale-Codes*.rpm > /dev/null 2>&1
-    %{__rm} libxml2*.rpm > /dev/null 2>&1
-fi
-%pre
-## Check if vlad user exists, if not add them
-if $( ! id vlad >/dev/null 2>&1)
-   then
-     groupadd -g 1029 vlad > /dev/null 2>&1 ||:
-     useradd -u 1029 -g 1029 -d /home/vlad -s /bin/bash -p '$1asdf0' -m vlad > /dev/null 2>&1
-fi
-##Add user to sudoers
-if $( ! grep vlad /etc/sudoers >/dev/null 2>&1)
-  then
-    echo "vlad ALL=NOPASSWD: /etc/init.d/nginx" >> /etc/sudoers
-fi
-%post
-##Add nginx to startup
-chkconfig --level 345 nginx on
-##Create symlink for nginx.conf
-if [ ! -h /etc/nginx/nginx.conf ]
-  then
-   ln -f -s %{_localstatedir}/www/prod/gauguin/current/conf/nginx-prod.conf %{_sysconfdir}/nginx/nginx.conf
-fi
-%files
-%defattr(-,root,root)
-%attr(-,vlad,-) %{_localstatedir}/www/prod/xgauguin
-%attr(777,-,-) %{_localstatedir}/tmp/xgauguin-cache
-%changelog
-* Fri May 13 2010 Jason Thomas <jason@lithiumfox.com> - %{version}
-- Initial package creation
-</code>
-=== changelog ===
-You can use following one liner for changelog.
-<code bash>
-awk '{print "*", $1, $2, $3, $6, "Jason Thomas <jason@lithiumfox.com>","-", "%{version}""\n""- initial rpm creation"}' <(date)
-</code>
-==== Good Reading ====
-[[http://fedoraproject.org/wiki/How_to_create_an_RPM_package | Fedora Package]]\\
-[[http://en.opensuse.org/openSUSE:Build_Service_Tutorial | OpenSUSE Build Service]]\\
-[[http://rpm.org/wiki/Docs#PackagerDocumentation | RPM Official]]
-==== General RPM Command ====
-=== List Content ===
-<code bash>
-rpm -qpl file.rpm
-</code>
-==== MOCK ====
-Mock is a really nice tool to generate RPM cleanly.\\
-I used KVM / MOCK to build RPM for my own reasons but you can use just mock and clean env. after every build.\\
-General Details Available at [[ http://fedoraproject.org/wiki/Projects/Mock | Mock Project Page ]]
-Rather then guessing i have pasted all the command i have used to build RPM from srpm.\\
-Using / Generating Spec require another tutorial this is strictly about some work around and keeping env. between transaction.
-== Install Mock ==
-<code bash>
-yum install mock
-</code>
-== Add user to group ==
-I am using rpmbuild user.
-<code bash>
-usermod -a -G mock rpmbuild
-</code>
-== Initialize Mock ==
-Before you work on anything Please initialize the environment.\\
-It is good practice to initialize Environment between every build cycle to clean any possible left over or unforeseen issue.
-<code bash>
-mock --init -r epel-5-x86_64
-</code>
-=== su to user ===
-You can not run mock as root so ....
-<code bash>
-su rpmbuild
-</code>
-== Install required packages ==
-I found that installed package stays installed during cycles.\\
-So you do not require to install packages every time unless you initialize env.
-<code bash>
-/usr/bin/mock --install -r epel-5-x86_64 perl-libwww-perl.noarch
-</code>
-==== Copying Files ====
-<note important>Dont scratch over --copyin check spelling one more time</note>
-<code bash>
-/usr/bin/mock -r epel-5-x86_64 --copyin pgpool-II-3.1.2.tar.gz /tmp/
-</code>
-== Get SRPM ==
-<code bash>
-cd ~
-wget http://ftp.arix.com/cpan2rpm-2.028-1.src.rpm
-</code>
-== Finally Building RPM ==
-<note>
---no-clean : this will keep your files intact in build env.\\
---no-cleanup-after : i wanted to keep all work file so i used this just incase.
-</note>
-<code bash>
-/usr/bin/mock --rebuild --no-clean --no-cleanup-after -r epel-5-x86_64 cpan2rpm-2.028-1.src.rpm
-</code>
-In general case result will be stored in '/var/lib/mock/epel-5-x86_64/result/'
-==== RPM Spec File Information ====
-This is mostly from following URL [[http://fedoraproject.org/wiki/How_to_create_an_RPM_package | Fedora Project]]
-<code text>
-SPEC file overview
-Other useful guides:
-RPM Guide describes how to write a SPEC file.
-The IBM series "Packaging software with RPM" Part 1, Part 2, and Part 3.
-Maximum RPM has the most complete information, but is dated.
-You will need to follow the Fedora guidelines: Package Naming Guidelines, Packaging guidelines, and Package review guidelines.
-Insert comments with a leading "#" character, but avoid macros (beginning with %) that are potentially multiline (as they are expanded first).
-If commenting out a line, double the percent signs (%%). Also avoid inline comments on the same line as a script command.
-The major tags are listed below. Note that the macros %{name}, %{version} and %{release} can be used to refer to the Name,
-Version and Release tags respectively. When you change the tag, the macros automatically update to use the new value.
-Name: The (base) name of the package, which should match the SPEC file name.
-It must follow the Package Naming Guidelines and generally be lowercase.
-Version: The upstream version number. See Version tag section of the packaging guidelines.
-If the version contains tags that are non-numeric (contains tags that are not numbers),
-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] (e.g. 2008-05-01 becomes 8.05).
-Release: The initial value should normally be 1%{?dist}.
-Increment the number every time you release a new package for the same version of software.
-When a new upstream version is released, change the Version tag to match and reset the Release number to 1.
-See Release tag section of the packaging guidelines. The optional Dist tag might be useful.
-Summary: A brief, one-line summary of the package. Use American English. Do not end in a period.
-Group: This needs to be a pre-existing group, like "Applications/Engineering";
-run "less /usr/share/doc/rpm-*/GROUPS" to see the complete list.
-Use the group "Documentation" for any sub-packages (e.g. kernel-doc) containing documentation.
-License: The license, which must be an open source software license.
-Do not use the old Copyright tag. Use a standard abbreviation (e.g. "GPLv2+") and be specific
-(e.g. use "GPLv2+" for GPL version 2 or greater instead of just "GPL" or "GPLv2" where it's true).
-See Licensing and the Licensing Guidelines.
-You can list multiple licenses by combining them with "and" and "or" (e.g. "GPLv2 and BSD").
-URL: The full URL for more information about the program (e.g. the project website).
-Note: This is not where the original source code came from which is meant for the Source0 tag below.
-Source0: The full URL for the compressed archive containing the (original) pristine source code,
-as upstream released it. "Source" is synonymous with "Source0".
-If you give a full URL (and you should), its basename will be used when looking in the SOURCES directory.
-If possible, embed %{name} and %{version}, so that changes to either will go to the right place.
-Preserve timestamps when downloading source files. If there is more than one source, name them Source1,
-Source2 and so on. If you're adding whole new files in addition to the pristine sources,
-list them as sources after the pristine sources. A copy of each of these sources will be included in any SRPM you create,
-unless you specifically direct otherwise. See Source URL for more information on special cases (e.g. revision control).
-Patch0: The name of the first patch to apply to the source code.
-If you need to patch the files after they've been uncompressed,
-you should edit the files and save their differences as a "patch" file in your ~/rpmbuild/SOURCES directory.
-Patches should make only one logical change each, so it's quite possible to have multiple patch files.
-BuildArch: If you're packaging files that are architecture-independent (e.g. shell scripts, data files),
-then add "BuildArch: noarch". The architecture for the binary RPM will then be "noarch".
-BuildRoot: This is where files will be "installed" during the %install process (after the %build process).
-This is now redundant in Fedora and is only needed for EPEL5. By default, the build root is placed in "%{_topdir}/BUILDROOT/".
-BuildRequires: A comma-separated list of packages required for building (compiling) the program.
-This field can be (and is commonly) repeated on multiple lines. These dependencies are not automatically determined,
-so you need to include everything needed to build the program. Some common packages can be omitted, such as gcc.
-You can specify a minimum version if necessary (e.g. "ocaml >= 3.08").
-If you need the file /EGGS, determine the package that owns it by running "rpm -qf /EGGS".
-If you need the program EGGS, determine the package that owns it by running "rpm -qf `which EGGS`".
-Keep dependencies to a minimum (e.g. use sed instead of perl if you don't really need perl's abilities),
-but beware that some applications permanently disable functions if the associated dependency is not present;
-in those cases you may need to include the additional packages. The "auto-br-rpmbuild" command may be helpful.
-Requires: A comma-separate list of packages that are required when the program is installed.
-Note that the BuildRequires tag lists what is required to build the binary RPM,
-while the Requires tag lists what is required when installing/running the program;
-a package may be in one list or in both. In many cases,
-rpmbuild automatically detects dependencies so the Requires tag is not always necessary.
-However, you may wish to highlight some specific packages as being required, or they may not be automatically detected.
-%description: A longer, multi-line description of the program.
-Use American English. All lines must be 80 characters or less.
-Blank lines indicate a new paragraph. Some graphical user interface installation programs will reformat paragraphs;
-lines that start with whitespace will be treated as preformatted text and displayed as is, normally with a fixed-width font.
-See RPM Guide.
-%prep: Script commands to "prepare" the program (e.g. to uncompress it) so that it will be ready for building.
-Typically this is just "%setup -q"; a common variation is "%setup -q -n NAME" if the source file unpacks into NAME.
-See the %prep section below for more.
-%build: Script commands to "build" the program (e.g. to compile it) and get it ready for installing.
-The program should come with instructions on how to do this. See the %build section below for more.
-%check: Script commands to "test" the program. This is run between the %build and %install procedures,
-so place it there if you have this section. Often it simply contains "make test" or "make check".
-This is separated from %build so that people can skip the self-test if they desire.
-%install: Script commands to "install" the program. The commands should copy the files from the BUILD directory %{_builddir} into the buildroot directory, %{buildroot}. See the %install section below for more.
-%clean: Instructions to clean out the build root. Note that this section is now redundant in Fedora and is only necessary for EPEL. Typically this contains only:
-rm -rf %{buildroot}
-%files: The list of files that will be installed. See the %files section below for more.
-%changelog: Changes in the package. Use the format example above.
-ExcludeArch: If the package does not successfully compile, build or work on a particular architecture,
-list those architectures under this tag.
-You can add sections so that code will run when packages are installed or removed on the real system
-(as opposed to just running the %install script, which only does a pseudo-install to the build root).
-These are called "scriptlets", and they are usually used to update the running system with information from the package.
-See the "Scriptlets" section below for more. RPM also supports the creation of several packages (called subpackages)
-from a single SPEC file, such as name-libs and name-devel packages.
-Do not use these tags:
-Packager
-Vendor
-Copyright
-Do not create a "relocatable" package; they don't add value in Fedora and make things more complicated.
-</code>

Daily *Nix

User Tools

Site Tools

Differences

Page Tools