RPM Package Building & Automated Package Manager

Transcription

1 RPM Package Building & Automated Package Manager Last Modified: May 25,2004 Version: By: Benjamin Arai This is an evolving project specification so, check back frequently for revisions and hints that might make your life easier. Caveats: If you are using your RedHat Fedora Core 1 installation in order test the Apt installation of rdesktop then you will need to run apt-get install XFree86-libs in order to satisfy any required dependencies before modifying your sources.list file to include only your source list. Rdesktop must install using only your sources.list entry. Any additional entries or sources will not be allowed. Overview The project is to create and distribute your own package. The packaging system you will be using is RedHat RPM s and the manager will be Apt. RPM s are among the standard packaging utilities used today by various Linux distributions and offer a plethora of options and package tracking utilities. A source application will be provided, which will have to be converted into a RPM and distributed through the Apt distribution method. The project will be graded in two parts. The first will include the proper creation and building of the RPM. This will include creating a RPM build environment and the specification file containing relevant and correct information. The second section will include proper distribution of the RPM package using the Apt manager. Assumption The test machine will be a UML system running RedHat 9. This is being done for two reasons. The first, RedHat 9 is the current version of Linux running in the labs. Second, I am running it in UML because if you somehow create a malformed packaged, it could corrupt or kill my operating system. I am also going to offer for download the actual installation I am going to be using for testing so, you guys may test your RPM s as well but since you all have root privileges on your own VMware RedHat installations from lab one, you will be able to test you own RPM s there as well. Summary The first section will require a build environment to be created. The RedHat default installation contains a default build environment under /usr/src/redhat but require root privileges, so you will not be able to use it. Creating a build environment is a simple task explained below. After a build environment has been created, you will then create a spec file containing all of the relevant information for the package and build building the RPM. Assuming the RPM(s) is created you will then build an Apt repository and distributes your RPM via the Apt system. The project will be graded based upon the building of the RPM and Apt installation. Building the RPM The first thing you need to do is build the actual environment in you home directory. This makes up some directories and a special. file used for holding some RPM macro variables.

2 Run the following commands to build the necessary directories and files to get started: mkdir ~/rpm mkdir ~/rpm/tmp mkdir ~/rpm/build mkdir ~/rpm/rpms mkdir ~/rpm/rpms/i386 mkdir ~/rpm/sources mkdir ~/rpm/specs mkdir ~/rpm/srpms touch ~/.rpmmacros That should be all of the files/folders you need to run a RPM build environment. The.rpmmacros file needs the following lines added to it. %packager Benjamin Arai <barai@cs.ucr.edu> %distribution RedHat Fedora Core 1 %vendor The University of California, Riverside %_topdir /path_to_my_home_dir/rpm The path_to_my_home_dir should be replaced with the path to you home directory. For example, my path in the CS department is /home/csmajs/barai. You are now ready to start building RPM s. You now need to download the source package to be converted to a RPM. This can be downloaded from: This is the source package you will have to modify and convert into a RPM. The package needs to be copied to ~/rpm/sources/. Then in the directory ~/rpm/specs you need to create a file called rdesktop spec this can be downloaded from: The spec file contains all of the information for the source package to be built into a RPM and the version information associated used for dependency checking. This is a powerful tool over standard source installations because it ensures dependencies are present before installation. At this point you have all of the files you need to build the package, but the configuration of the actual RPM is the key to creating a good RPM. A badly written spec file can cause not only problems building/installing the package but also problems associated with stability. Some SPEC file sources. The actual SPEC file I used. rdesktop spec The link is also given in the above section. Proper parameters in the spec file follow all the way thru installation and into running the application. If you spec file does not have the proper dependency settings, then when the application is installed and ran on a host system it may fail or have sporadic errors. Once you have finished editing the spec file, you will then run the following command from ~/rpm/specs : rpmbuild -ba rdesktop spec

3 This will build the rdesktop RPM and put the final RPM in ~/rpm/rpms/i386. Depending upon the system architecture the directory may change, such an AMD x86_64 binaries are stored in ~/rpm/rpms/x86_64. Once the compiling and building has completed the final line should contain the line exit 0. If it does not then an error has occurred and the spec file needs to be further modified. Once the RPM has been built successfully you are now done and the RPM is ready to be used. Installing/Preparing Apt for RedHat This section is a little more hands-off than the previous RPM creation section. You will need to read the directions carefully and make a couple of leaps yourself. The section is easy. So, don t think too hard. Creating your own apt repository is probably much more simple than you'd think. The data needed by apt only represents about 1MB for an entire Red Hat Linux distribution (once compressed with bzip2, which is recommended), and with a local Red Hat Linux mirror, you can generate an apt repository within minutes. Here are a few files that will help you in doing so: genaptrep.sh - The shell script I use to generate all my repositories (for apt 0.5.x only, old 0.3.x version here) apt-tree.tar.gz - The directory tree needed by the genaptrep.sh script, including all the "release.*" files Note: The packages above are supplied to help you but are not needed in order to complete the project; in fact the description below assumes you are building the repository from scratch. You are not going to be creating a mirror repository but only a repository for you single RPM package you are creating. Requisites Note: This section is not going to be implemented but I included it for completeness, since you already have a usable web directory available in you CS home directories. For the project you will be using you own CS home directories to simplify the project. Assuming a minimal install of Fedora Core 1, you are going to have to install the Apache web-server and start it up. Apache is the server used for distributing the RPMS(s) and RPM(s). Run the following commands as root: apt-get update apt-get install httpd /sbin/service httpd start Assuming the server started with no errors, you should now have a running httpd server. The root of your website/repository is var/www/html. For you guys its going to be /home/csmajs/(your_username)/.html. In a professional environment this will not do because most likely your web-server is going to have hundreds of websites on it, so before finishing the project take a look at the virtual host setup in the last section because it will be very helpful in future labs. Repository structure Note: This section refers to RedHat 7.2 and 8.0 for creating a repository. This is only an example, you will need to make the necessary modifications to make it work for Redhat 9.0 or Fedora Core 1 for the project.

4 Here is a tree to give you an idea of what's in my opinion the easiest and most user-friendly repository structure. I've adopted it after discussing with other repository administrators (see explanation and examples here): apt - redhat en -+- i386 - os, updates, freshrpms +- s390 - os, updates +- ja --- i386 - os, updates en --- i386 - os, updates, freshrpms I guess you get the idea. This was inspired by Red Hat's official ftp hierarchy organization. So what we need to have is a directory structure similar to the above, for example the last line is "apt/redhat/8.0/en/i386". Then inside each "architecture" directory, we will need to have something similar to this: i base +-- RPMS.os +-- RPMS.updates +-- RPMS.freshrpms +-- SRPMS.os +-- SRPMS.updates +-- SRPMS.freshrpms The main problem with the apt repository structure is that it expects all binary packages to be in one directory, and all source packages in another. While this is true with the main Red Hat Linux distribution with "redhat/linux/8.0/en/os/i386/redhat/rpms" and "redhat/linux/8.0/en/os/i386/srpms", it isn't true with the updates, which do have all sources in a single "linux/updates/8.0/en/os/srpms" directory but binaries in various different architectures specific ones. Before creating the repository The "base" directory contains some manually created "release" files for each module (like "os", "freshrpms", aka "module"). These can be found in my apt tree skeleton. The program used to generate the apt metadata, "genbasedir" will create all the other needed files inside that "base" directory and expects to find all binary and sources packages for a given "foo" module under the "RPMS.foo" and "SRPMS.foo" directories, respectively, that are right next to it. From what was said earlier, you can see that we can easily create "RPMS.os" and "SRPMS.os" as symbolic links to the directories in the original Red Hat Linux directory structure, but for the updates and similar "complex" trees, we need another solution. The solution I use is the following: I create a real "RPMS.foo" directory, then each time just before running genbasedir, I erase all its content and run "find" to search for all binary packages in a certain place and have them all hard linked directly inside "RPMS.foo". This is what my script does for "RPMS.updates" as well as "RPMS.freshrpms" and "SRPMS.freshrpms".

5 This section does not require and changes to the directory but instead offer an important overview perspective what the Apt structure should and does look like. This includes the possibility of adding additional repositories to a given website. Creating the repository Here is an example, following what we've had to deal with above. Say we have: All Red Hat Fedora Core 1 files in /home/csmajs/barai/.html/aptpkgs/fedora/linux/1/i386 For mine, I added one more directory called RPMS.barai for completeness. This will allow me to add additional repositories in the future and etc. So, the final structure looked like in /home/csmajs/barai/.html/aptpkgs/fedora/linux/1/i386/rpms.barai for the barai repository. All we need to run (with apt 0.5.x, not 0.3.x) is: genbasedir --flat --bloat --bz2only ~/.html/aptpkgs/fedora/linux/1/i386 barai And this will create all the needed apt metadata in the "base" directory, assuming we've already done all the needed hard linking or copying for the binary packages from the updates. Make sure you run this command from inside the /home/csmajs/(your username)/.html/aptpkgs/fedora/linux/1/i386 directory and that the RPMS to be indexed into the repository are present in a directory created as specified in the previous section. Note: For the project it is easiest to just copy the binary packages to the appropriate directories instead of creating hard links. Making the repository available The repository is now available to the public. The address users will use the same address your server is connected to. Once this is done, clients can use the repository by putting these entries in their /etc/apt/sources.list file: rpm fedora/linux/1/i386 barai or if you are using your home directory account: rpm fedora/linux/1/i386 barai That s it. At this point you should have everything running without a problem. Make sure you run a test apt-get install rdesktop using only the source.list you have for your server.