Fedora Linux Support Community & Resources Center
Old 1st May 2007, 01:01 PM
hidepenny Offline
Registered User
Join Date: May 2007
Location: Melbourne, Australia
Posts: 24
what to use to create RPM?

there's installshield and wise for MS windows creating MSI packages

what do people use to create RPM packages?

Thanks in advance!
Reply With Quote
Old 1st May 2007, 01:35 PM
ms1234 Offline
Registered User
Join Date: Apr 2005
Posts: 323
Reply With Quote
Old 1st May 2007, 03:51 PM
LinuxTom Offline
Registered User
Join Date: Jul 2005
Location: Kentucky, U.S.A.
Posts: 355
RPM's don't have any real tool such as installshield for their creation. Best bet is to study the link ms1234 provided, and install rpmdevtools, then you can use rpmdev-newspec to create a bare spec file for the RPM you want to build. It's gonna be trial and error till you get the hang of it though.
Reply With Quote
Old 2nd May 2007, 03:18 AM
foolish Offline
Retired Community Manager
Join Date: Feb 2004
Location: Aalesund, Norway
Age: 30
Posts: 1,888
Maybe it'll be useful if I describe how I go about creating an rpm package for Fedora. As stated above it's not an automated process.There are some basic steps I always take however. This'll be long and full of repetitions, as the rpm building process itself.

Note: this is not a tutorial, following these steps will not get you an rpm package. This is more to give you a basic idea of the process of creating an rpm and why it isn't automated. This is fedora-centric and I use fedora tools all the way. These tools are rpmbuild, rpmlint, the scripts from rpmdevtools, mock, yum and rpm itself.

Basic understanding of tarballs, and common methods of compiling and installing software such as ./configure && make && make install is assumed and required for buildign rpms. Compiling the software using these same tools is part of building the RPM.

1. Find open source software that is not available from Fedora already. I'll use the example of cowbell here, which is a package I maintain for Fedora Extras currently. Cowbell is a nice piece of software to manage a music collection. It's web page is: http://more-cowbell.org/

2. At the cowbell page, get the source tarball link. I don't close the web page, as I'll use it to get information later.

3. At this point I open my terminal and go to my /home/foolish/rpmbuild/. This directory was created the by fedora-buildrpmtree script. It contains BUILD, RPMS, SOURCES, SPECS and SRPMS dirs

4. I go into SOURCE and wget the cowbell source tarball to my local SOURCE dir.

5. I untar the tarball: tar -xvzf cowbell- and cd into it. Now I can observe which files are available from the tarball. Usually, and in this case, there's an INSTALL file explaining how to compile the software I've just downloaded. I read this to get an idea how to do the compiling.

6. At this point I open a new terminal window/tab and go to the /home/foolish/rpmbuild/SPECS dir. Here I use the fedora-newrpmspec script to create a script template. In most cases I use the generic template, but in some cases I use a special template like the python one. I know which to use due to reading the INSTALL earlier. In this case I only use the basic template.

7. I open the newly created cowbell.spec in the gvim editor. I use gvim because I like vi and because it has nice syntax highlighting. Any text editor will do fine.

8. Now I start filling out the information I have gathered so far. The website is useful here. As are the standard documentation files from the source tarball. The COPYING file contains the licencing information, the README has a description and a summary and so forth. I get the full tarball link for the Source0 from the website and paste it in.

9. This is where I usually comment out the BuildRequires and Requires fields by adding a # in front. I'll get back to these later.

10. Check the %setup. If the directory you got from the source tarball doesn't match the usual %{name}-%{version} scheme, add an -n option and enter the directory from the source tarball.

11. in %build, I add build instructions as I see fit. You'll get information from reading INSTALL from the tarball, and doing ./configure --help in the extracted source directory.

12. in %install I add the install instructions as I see fit. In my case I dont' have to change anything here.

13. I leave the %files section as is apart from entering the file names of useful documentation files from the tarball into the %doc line, such as AUTHORS, ChangeLog, README and COPYING, I also a basic changelog entry.

Now begins the fun part, the trial and error.

14. I now try to build the spec file as it is and look at the output. This won't succeed, but it will give me a lot of good info. If it fails on syntax errors, rpmbuild will tell me. If I've gotten all that I've filled in untill now right, it will most likely fail during the %configure part as I'm missing some -devel dependencies.

15. %configure is just ./configure with some special options. As with a basic compile, you'll have to yum install the dependencies missing. Fill them in to your Spec as BuildRequires. I only enter the ones that are really needed. So if I require gtk-sharp2-devel, which again requires gtk2-devel, I only need to enter gtk-sharp2-devel as the gtk2-devel package will be pulled in anyway. Once added, try to build again. Repeat untill you get past %configure. You don't have to add Requires for the -devel dependencies that you've added BuildRequires. RPM is smart enough to figure this out, so if you're package depends on gtk-sharp2-devel to build, the binary rpm will automatically depend on gtk-sharp2. I don't worry to much about getting all the dependencies right at this time, I just try to get past %configure without errors.

16. Now watch make succeed or fail. This is the same process as make in the traditional build and install method. Usually, this will succeed if you get past %configure. If it don't, debug. This may require knowledge about the software itself or at least the gnu buildtools. If this happens to me I contact the developers and ask for help.

17. Once the rpmbuild process gets to %install, it will try to make install and then complain about files that are built but not packaged, and list these. This is the list of files you then add to %files, only replacing the path names with the system variables. so if /usr/bin/cowbell is listed, I add %{_bindir}/cowbell to my %files list. I add all the files listed as built but not packaged this way. Rebuild your .spec once more. At this point it should build successfully. The RPM is not done yet however, not at all.

18. Now I add scriplets. These are scripts needed in the %install part of my spec to ensure that various elements of my package is handled correctly. Remember the goal of packaging rpms here, if the package installs it should work flawlessly, the scriplets ensure that. Put the scriplets in between the %install section and the %files section. A list of scriplets, how to use them and when they are needed can be found at: http://fedoraproject.org/wiki/ScripletSnippets. I add the scriplets I need. I now rebuild my package.

19. At this point I go back to the build dependencies. Since my build system, which is also my desktop, contains a lot of packages, it may be that some package I have installed has been passed by the %configure process earlier and as such hasn't been added to the BuildRequries: list. I use mock to make sure I have all the dependencies really needed to build the package. Mock is used to rebuild the SRPM I've now created in a special isolated root, and uses yum to install only the basic dependencies + the ones I've listed. As such, the mock build will fail if the configure script in the isolated root isn't able to locate files required to complile the I try to build in mock, if it fails I add the dependencies that was missing, I find this in the build.log in my mock resultsdir. I'll rebuild untill I have a successful mock build. Trial and error, keep at it 'till it succeeds.

Note: mock is slow and a mock build takes a long time. Use the --no-clean and --autocache options to speed it up. Once you've built a few packages you'll be able to recognise patterns of dependencies and as such won't have to build in mock so many times to get all the dependencies right.

20. At this point I'm getting close to a fully functional and complete RPM package. I now go to the RPMS and SRPMS dir and locate my now mock-passed rpm -debuginfo.rpm and src.rpm. I run the rpmlint script on all of these packages. rpmlint will notice me of common mistakes in the spec file, such as syntax errors, wrongly placed files or other mistakes that are usually easy to fix. I try to fix this, rebuild, and run rpmlint again. I now repeat this untill I get no output at all from rpmlint. Instructions on how to resolve various rpmlint issues are in the rpmlint manual.

21. Once I have an rpm that builds in mock and has no rpmlint output, I install the binary (in my case i386) rpm package I've created. I check for scriplet errors during install and fix these in the spec if needed. Once package is installed without any output, I check that the expected behavior is achieved. In the case of cowbell this means that there should be an entry in the menu under Sound & Video, if I right click a .ogg or .mp3 cowbell should be listed as a possible application to launch it in. Cowbell should of course run, and behave as expected. If there are issues, I launch cowbell in a terminal. I may have forgot about a Requires: that wasn't automatically pulled or something else may be wrong. I go back to my spec file and try to fix them, or contact upstream to make sure if the problem is with my build, or in the project itself.

Once I have a package that builds in mock, has a silent rpmlint, contains the right scriplets and behaves as expected when installed, I'm happy. At this point I submit the package for review so that more experienced packagers can point out my mistakes.

To see the finished spec file, get the cowbell SRPM from a fedora-extras SRPM mirror and install it as user. It will put the .spec into your SPEC-dir and the source tarball into your SOURCES dir.

Hope this is somewhat useful to illustrate how an rpm is created. Every package is different though, but the basic steps of adding information, getting it to compile, adding files to %files, adding scriplets, mock, rpmlint and runtest are the same. See the http://fedoraproject.org/wiki/Packag...viewGuidelines for more on what is required of a good RPM package.
Sindre Pedersen Bjørdal || http://www.fedorasolved.org || Hardware Profile
- Please adhere to the FedoraForum Guidelines.

Last edited by foolish; 2nd May 2007 at 03:28 AM.
Reply With Quote
Old 2nd May 2007, 03:31 AM
Firewing1 Offline
Registered User
Join Date: Dec 2004
Location: Canada
Age: 25
Posts: 9,223
I have a RPM building howto if you'd like to start by rebuilding a few - Once you get the hang of it, you can start building whatever you like really.
[+] My open source software and blog
[+] Some of my howtos: (for full list, click here)
Reply With Quote

create, rpm

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Create a pdf from c++ daviddoria Programming & Packaging 2 30th October 2008 03:37 AM
How to create iso baloon Installation, Upgrades and Live Media 6 22nd December 2006 04:45 AM
Create an .iso? leadgolem Using Fedora 5 27th September 2006 10:25 AM

Current GMT-time: 22:52 (Sunday, 26-03-2017)

TopSubscribe to XML RSS for all Threads in all ForumsFedoraForumDotOrg Archive

All trademarks, and forum posts in this site are property of their respective owner(s).
FedoraForum.org is privately owned and is not directly sponsored by the Fedora Project or Red Hat, Inc.

Privacy Policy | Term of Use | Posting Guidelines | Archive | Contact Us | Founding Members

Powered by vBulletin® Copyright ©2000 - 2012, vBulletin Solutions, Inc.

FedoraForum is Powered by RedHat