User Tools

Site Tools


rpm

Differences

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

Link to this comparison view

rpm [2012/04/12 18:24]
k2patel [Copying Files]
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>​ 
rpm.txt ยท Last modified: 2020/08/10 02:35 (external edit)