Linux Application Packaging

 Original Address: http://blog.solrex.cn/articles/packaging-1-src.html
1. One of the application packaging Technologies (source code)

I believe many friends have written their own small program for the convenience of doing something (like I wrote casnet , sendsms , but a lot of fear is hidden in the mountains no one knows, and finally nothing, they also left them in the corner to forget.

Uploading these gadgets to a technology forum or a website such as the CSDN download channel will still receive some attention, and can save points and prestige. But why not publish them? There are several reasons: the source code is too messy, compiling and quite complicated, sorry to show others; The binary package will not hit, do not know how to publish.

So I'm going to share my program packaging experience in this series of articles, and there are currently four projects: source code, Deb, RPM and EXE. These technologies can be found on the web, because I am also learning from the Internet, a note and a summary of it. If you have good criticisms or suggestions, you may wish to point it out in the comments and help me refine this article.

Source Code Chapter

Releasing a source code package is the simplest thing to do, so it is also the first to be introduced. There is a reunion said, a compressed package is not finished. This is true, but there are a few things to note before you compress:

1. Delete the version management directory, such as the. Svn,.cvs directory. like Subversion version management software, a directory named. SVN is created in each directory, which typically holds the latest version of the file in the directory and can be used to revert changes. Not deleting the. SVN directory will make the source code package bloated, and most importantly, there may be security implications. The SVN directory also contains your user name and SVN server information, which you may not want to let others know. But if you're fast enough, you can re-export a copy of your SVN, instead of just copying it from your svn tree, there's No. svn directory.

2. to normalize the compilation process, if the compilation process is not standardized, you should add a README. If your code is not a script, you probably need to compile the user. If the compilation process specification, *nix (Linux/unix, CygWin, MINGW, etc.) is./configure, make, make install, the user is easy to understand. However, if the compilation process is not standardized, you may want to add a README or INSTALL file to instruct the user how to compile. Users of MS VisualStudio should pay attention to the cleanliness of the project file, preferably export a Makefile (yes, VS can also be used Makefile), so that users do not have to open the project, the CMD command line with NMAKE Makefile can be compiled.

3. Delete the binary intermediate file. in *nix developers, this is generally not difficult to do, Makefile generally write a clean target, but MS VS users generally do not pay attention to those generated at compile time. obj file. The source code package should be source code, containing at most executable programs and documents, and should not contain any other binary files. Otherwise, your source code package will be very large, and the user is also troubled, in the end, which files are useful?

4. modify the compilation target from the debug version to the release version. *nix, this generally means that CFLAGS to change to-o2 rather than-g;vs generally means moving the target from debug to release. This allows the user-generated executable program to be small enough and fast enough that they will know how to change the options back if they have the ability to debug themselves.

5. The addition of intellectual property information is an authorization agreement. Small program people generally don't care, but if you spend enough effort on this project, it is best to choose a license agreement that you like. You can place the protocol declaration in the first note of each source file, or you can drop a license file at the root of the project.

6. do not use RAR packages. Zip compression is recommended under Windows, and *nix is recommended for use with the. tar.gz or. tar.bz2 format. Because these formats do not need to install additional software decompression on these systems. The WinRAR is a commercial software, and the RAR format is also protected by copyright.

Package Command:

Under Windows, if you use open source software 7-zip to compress a zip package, you can use this command (first add the 7-zip executable directory to the PATH environment variable):

7z a foo.zip foo

Under the *nix, there are a few commands:

Tar czvf foo.tar.gz foo
Tar cjvf foo.tar.bz2 foo
Zip-r foo.zip foo

2. Application Packaging Technology II (Deb article)

Deb is the package format used by Debian Linux and the package format I most appreciate. There are two ways I know to play the Deb package, one is to use Checkinstall, and the other is to use dpkg.

Checkinstall can be used not only for the Deb package, but also for the RPM and tgz packages, and is relatively simple to use. But Checkinstall's operation is not so stable, I do not understand it under what circumstances to run normally, and its customization is not very strong, always use to enter some information interactively, so I still gave up using it to package software. Interested friends can search the internet for how this program is used.

Dpkg is Debian's "native" package management software, but many people are reluctant to use dpkg to package Deb. The reason may be the need to write a troublesome configuration file, but one of the benefits of writing a configuration file is that you can use the last configuration file in the next time you package, just modify a version number, instead of having to fill in the package information every time. Before we introduce how to make a deb package, let's look at how to unpack the Deb package.

$ sudo apt-get install tree
$ dpkg-x/var/cache/apt/archives/tree_1.5.1.1-1_i386.deb Fakeroot
$ CD Fakeroot
$ dpkg-e/var/cache/apt/archives/tree_1.5.1.1-1_i386.deb
$ tree
.
|--DEBIAN
| |--Control
| '--md5sums
'--usr
|--bin
| '--Tree
'--Share
|--doc
| '--Tree
| |--README
| |--Changelog. Debian.gz
| |--changelog.gz
| '--copyright
'--Man
'--Man1
'--tree.1.gz

Dpkg-x is the content file of the Deb package is released, DPKG-E is to release the control information of the Deb package. the previous sudo apt-get install tree was executed to download the tree_1.5.1.1-1_i386.deb to the local apt cache, and if you have already installed the tree, you can add the-d parameter to the Apt-get So that it is downloaded only and not installed.

From the execution results of the tree command above we found that theDeb package was unpacked after two parts: part of the control information in the DEBIAN directory, and part of the installation content in the USR directory. Now you probably understand why we use Fakeroot as the directory name, because this directory is a "Rhizoids directory", all of your changes in this directory will eventually be mapped to the target machine root directory/down. For example Fakeroot/usr/bin/tree this file, it will be installed under/usr/bin, and so on.

As long as you can understand fakeroot this directory mapping, you know how to put your own files. In order for the generated package to install file Foo into the directory/usr/xx/yy directory, you can only use the Fakeroot directory to create the Usr/xx/yy directory and copy foo into it.

OK, here's the key configuration file section, about control and md5sums.

$ more Debian/control
Package:tree
Version:1.5.1.1-1
Architecture:i386
Maintainer:ubuntu MOTU Developers
Original-maintainer:florian Ernst
installed-size:92
DEPENDS:LIBC6 (>= 2.6-1)
Section:utils
Priority:optional
Description:displays directory tree, in color
Displays an indented directory tree, using the same color assignments as
LS, via the ls_colors environment variable.
.
homepage:http://mama.indstate.edu/users/ice/tree/

We can see that thecontrol file contains mainly software version and maintainer information, I believe we can basically understand the above information what it means: Package name (tree), version (1.5.1.1-1), Architecture Target Architecture (i386 386 and later), maintainer maintainer (Ubuntu MOTU developers), Original-maintainer original maintainer (Florian Ernst), Installed-size installed size (92K), Depends dependent package (Libc6 not less than 2.6-1 version), section Package Classification (tool), priority precedence (optional), Description package Description, homepage Software home page.

since we analyze this package is the Ubuntu release package, so the package information to the comparison of all, in fact, not all the information above is necessary to provide (whisper, even if the full offer is not difficult?) Except for what we don't need, original-maintainer this. For information about what is important, and the specific meaning and options of each domain, you can refer to the Debian documentation Debian Policy Manual Chapter 5-control files and their fields .

You can also leaf out, write a similar control file to the DEBIAN directory, provide some of your own package information, basically this configuration file can be packaged.

$ more Debian/md5sums
D60A3B4736F761DD1108CB89E58B9D4E Usr/bin/tree
981EA0343C2A3EB37D5FC8B5AC5562DF usr/share/man/man1/tree.1.gz
483a56158a07a730ec60fc36b3f81282 Usr/share/doc/tree/readme
Ea56d78ae0d54693ae8f3c0908deeeff Usr/share/doc/tree/copyright
4456E04C3C268EABCD10EE9B949A9B9A usr/share/doc/tree/changelog.gz
EC104DB6914CFCE2865A0D8C421512BB Usr/share/doc/tree/changelog. Debian.gz

Md5sums, this file name at a glance, it is stored in the package file MD5 checksum, to verify whether the package is damaged. in fact, this document is purely "30 catch rabbit, there is no it is the New Year", you can not provide it at all.

So, we're ready. Content files and control information for the Deb package: The control file is placed under the Fakeroot/debian directory, the content file is placed under FAKEROOT/USR, and the directory tree is like the result of the start tree command. The following only requires one command to be able to call out the Deb installation package:

$ CD.
$ dpkg-b Fakeroot/foo.deb

Foo.deb appears in the current directory. You can use Dpkg-i foo.deb to view foo.deb control information, dpkg-c foo.deb see what files are included in Foo.deb, sudo dpkg-i install Foo.deb.

Tips:

1. If you are too lazy to create a new control file and directory tree, you can find a simple package, release its content and control information, modify it, and then print out its own package, as the beginning of this article.

2. It is not difficult to generate md5sums files, you only need to use the following command in the Fakeroot directory:

$ Md5sum ' find Usr-type f ' > Debian/md5sums
Or
$ find usr/-type f-exec md5sum {} + > Debian/md5sums

3. Copying your executable files to FAKEROOT/USR does not necessarily have to be manually copied. If you are using the GNU automatic toolset, add a parameter--prefix=fakeroot/usr/to the./configure when you write your own Makefile, you can use a variable prefix=/usr in Makefile, and when you do not add parameters, The install target for make install is/usr, you can use MAKEFILE-E Prefix=fakeroot/usr/install to override the variable settings in Makefile.

3. Application Packaging Technology III (RPM article)

RPM is the package format used by the RedHat system Linux. Popular Linux distributions: Fedora, RHEL, OpenSUSE, Oracle including the domestic red flag Linux, all using RPM to manage packages.

I don't really like the RPM package format for two main reasons, one is that its dependencies are difficult to handle and the other is the complexity of the control file. However, the RPM package has a very wide range of applications and is also an important tool for improving productivity.

As mentioned in the previous article, Checkinstall can also be used to play RPM packages, but I am not very familiar with this software. Here I'll just show you how to use the original RPM (Rpmbuild) tool to hit the RPM package.

As with the previous Deb package using Fakeroot, the Rpmbuild is also a sandbox way to build packages, and the process may be more automated in addition to the cumbersome control files. The working directory for building RPM packages is/usr/src/redhat by default, which may be/usr/src/rpm if you install the RPM package under Debian. You can use the RPM--eval%_topdir to view your rpm working directory.

$ Tree ' rpm--eval%_topdir '
/usr/src/redhat
|--BUILD
|--RPMS
| |--Athlon
| |--i386
| |--i486
| |--i586
| |--i686
| '--Noarch
|--SOURCES
|--SPECS
'--SRPMS

We can see that there are several subdirectories under/usr/src/redhat/: SOURCES is used to store the source code package, SPECS is used to store the spec control file, the build is used to extract the source code and build the software, the RPMS is stored in a good binary application RPM package, The SRPMS is stored in a good source RPM package. However, we should know that _topdir can be modified in the spec file, otherwise we can only use root to create files and execute commands under the default working directory/usr/src/redhat. We can first copy the working directory tree to the user's own directory:

$ cp-r/usr/src/redhat ~/rpm

In this way, we can play the RPM package under the user directory ~/rpm. There are only two pieces of preparation before the RPM package: 1. Prepare the source code package and place it in the SOURCES directory; 2. Prepare the spec control file and place it in the SPECS directory. How to hit the source code package we have already introduced in the source code article, the following we mainly introduce the format of the spec file. The following is an instance of the spec file.

$ more ~/rpm/specs/casnet.spec
%define _topdir/home/solrex/rpm
Name:casnet
version:1.3
Release:1
License:gpl
Packager:solrex Yang
Summary:casnet Client
Group:network
Source:%{name}-%{version}.tar.gz
url:http://share.solrex.cn/casnet/
Prefix:/usr

%description
Casnet is a GUI client for IP gateway of Gucas (graduate University of Chinese
Academy of Sciences), which is written in Python and PYGTK.

%prep
%setup-q

%build

%install
MAKE-E Prefix=%{prefix} Install

%files
%{prefix}/bin/casnetconf
%{prefix}/bin/casnet
%{prefix}/bin/casnet-gui
%{prefix}/share/casnet/casnetconf.py
%{prefix}/share/casnet/casnet.py
%{prefix}/share/casnet/casnet-gui.py
%{prefix}/share/casnet/pics/*.png
%{prefix}/share/applications/casnet.desktop
%{prefix}/share/icons/casnet.png

We can see that the spec file has a lot in common with the control file of the Deb package: Name, version, release, License, Packager, URL is the name of the software, the version, the iteration, the protocol used, the maintainer, and the URL; summar Y and%description are software information, and Group is the category of software. The rest is a little different: source refers to the software source code package name, RPM will go to the SOURCES directory to find the package, Prefix is the default installation location of the software,%prep,%build,%install are software preprocessing, compiling and installation commands; Files are all documents that need to be packaged in.

Therefore, the author needs to complete the fields in the spec file correctly. %PREP%setup macro is generally used to release the source code tar package into the BUILD directory,%build can add%configure macros and make commands, if your software needs to compile,%install is your installation command;%files is your All the files required for the program to run, the path is where it should be when you finish installing the software. %{name} can be used to refer to the name: the contents of the domain,%{version} refers to the content of version: domain, and so on.

It is important to note that Rpmbuild uses build/%{name}-%{version} as your source code package after the release of the directory, into which to compile. So when you use tar to source code packages, the top-level directory name of the tar package should be%{name}-%{version} instead of just%{name}, such as:

$ tar czvf casnet-1.3.tar.gz casnet-1.3
$ mv casnet-1.3.tar.gz ~/rpm/sources

Now that we have the casnet-1.3.tar.gz under the ~/rpm/sources and Casnet.spec in the ~/rpm/specs directory, we can use the following command to generate the RPM package. If your installation location Prefix selects a system directory, such as/usr,/usr/local, you may need to run the Rpmbuild command with root privileges.

$ rpmbuild-ba ~/rpm/specs/casnet.spec

This allows us to get the RPM packages we generated in the ~/rpm/rpms/i386 directory. The execution of the Rpmbuild command is like this: first locate the source code package according to the spec file, then release the source code package into the build directory, compile and install the commands given in the spec file, and then extract the files listed in the spec, and make the RPM package according to the package information.

We can use the RPM-QPI command to view the RPM package information, the RPM-QPL command to see the list of files included in the RPM package:

$ RPM-QPI ~/rpm/rpms/i386/casnet-1.3-1.i386.rpm
Name:casnet Relocations:/usr
version:1.3 Vendor: (None)
Release:1 Build date:thu 08:03:50 PM CST
Install Date: (not installed) Build Host:laptop
Group:network Source rpm:casnet-1.3-1.src.rpm
size:40883 LICENSE:GPL
Signature: (None)
Packager:solrex Yang
url:http://share.solrex.cn/casnet/
Summary:casnet Client
Description:
Casnet is a GUI client for IP gateway of Gucas (graduate University of Chinese
Academy of Sciences), which is written in Python and PYGTK.

$ RPM-QPL ~/rpm/rpms/i386/casnet-1.3-1.i386.rpm
/usr/bin/casnet
/usr/bin/casnet-gui
/usr/bin/casnetconf
/usr/share/applications/casnet.desktop
/usr/share/casnet/casnet-gui.py
/usr/share/casnet/casnet.py
/usr/share/casnet/casnetconf.py
/usr/share/casnet/pics/casnet.png
/usr/share/casnet/pics/offline.png
/usr/share/casnet/pics/online.png
/usr/share/icons/casnet.png

Linux Application Packaging