- 论坛徽章:
- 0
|
https://wiki.ubuntu.com/PackagingGuide/Complete
Introduction
" lang="en">">
Welcome to the Ubuntu Packaging Guide! This guide is primarily addressed to those who would like to make and maintain Ubuntu
packages. Although many of the concepts in this guide could be used to
make binary packages for personal use, it is designed for those people
wanting to distribute their packages to and for others. While it is
also written with the Ubuntu Linux distribution in mind, it should also be useful for any Debian-based distribution.
There are several reasons you might want to learn how to package for Ubuntu. First, building and fixing Ubuntu packages is a great way to contribute to the Ubuntu community. It is also a good way to learn how Ubuntu and the applications you have installed work. Maybe you want to install a package that is not in the Ubuntu
repositories. Hopefully after you have completed this guide you will
have the tools and knowledge you need to do all of these things.
">
Where to Begin
If you are
completely new to Debian-based packaging then you will want to read
this guide completely through, paying special attention to the section
called
Prerequisites
, and the section
Basic Packaging
. People who are experienced with Debian-based packaging will find section
Ubuntu Packaging
and section
Bugs
most helpful.
Prerequisites
This guide
assumes that the reader has a reasonable knowledge of building and
installing software from source on Linux distributions. The guide also
uses the Command Line Interface (CLI) throughout, so you should be
comfortable using a terminal. You should be able to at least use the
following:
" lang="en">">
- make:
GNU Make is a very important software building tool. It is used to
transform a complex compilation task into a trivial one. It is
important that you know how to use it, because we will store most of
the information about the packaging process in a Makefile.
Documentation is available at the
GNU
website.
- ./configure:This
script is included in almost all Linux source, especially for software
written in compiled languages such as C and C++. It is used to generate
a Makefile (file used by make) that is
properly configured for your system. Standard Debian packaging tools
use it, so it is important that you know what the configure script does. Information on ./configure can be found in the make documentation.
- Apt/Dpkg: Beyond the basic use of installing programs, apt and dpkg have many features that are useful for packaging.
- apt-cache dump - lists every package in the cache. This command is especially helpful in combination with a grep pipe such as apt-cache dump | grep foo to search for packages whose names or dependencies include foo.
- apt-cache policy - lists the repositories (main/restricted/universe/multiverse) in which a package exists.
- apt-cache show - displays information about a binary package.
- apt-cache showsrc - displays information about a source package.
- apt-cache rdepends - shows reverse dependencies for a package (which packages require the queried one.
- dpkg -S - lists the binary package to which a particular file belongs.
- dpkg -l - lists currently installed packages. This is similar to apt-cache dump but for installed packages.
- dpkg -c - lists the contents of a binary package. It is useful for ensuring that files are installed to the right places.
- dpkg -f - shows the control file for a binary package. It is useful for ensuring that the dependencies are correct.
- grep-dctrl - searches for specialized information in packages. It is a specific use of the grep package (but not installed by default).
- diff and patch:
- The diff program can be used to compare two files and to make patches. A typical example might be diff -ruN file.old file.new > file.diff. This command will create a diff (recursively if directories are used) that shows the changes, or delta, between the two files.
- The patch program is used to apply a patch (usually created by diff or another similar program) to a file or directory. To apply the patch created above, we can invoke patch -p0 . The option -p tells patch how much it should strip from the paths for the file names in the patch. The option -p0 means to strip nothing, or leave the path intact.
">
Getting Started
Binary and Source Packages
Most users of a Debian-based distribution such as Ubuntu
will never have to deal with the actual source code that is used to
create all of the applications on their computers. Instead, the source
code is compiled into binary packages from the source
package that contains both the source code itself and the rules for
making the binary package. Package maintainers upload the source
packages with their changes to the build systems that then compile the
binary packages for each architecture. A separate system distributes
the generated binary .deb files and source changes to the repository
mirrors.
Packaging Tools
" lang="en">">
There are many tools written specifically for packaging on Debian-based systems. Many of them are not essential to creating packages but are very helpful and often automate repetitive tasks. Their man and info
pages are good sources of information. However, the following is a list
of packages that are deemed necessary to begin packaging:
- build-essential is a metapackage that depends on libc6-dev, gcc, g++, make, and dpkg-dev. One package that you might not be familiar with is dpkg-dev. It contains tools such as dpkg-buildpackage and dpkg-source that are used to create, unpack, and build source and binary packages.
- devscripts contains many scripts that make the packager's maintenance work much easier. Some of the more commonly used are debdiff, dch, debuild, and debsign.
- ubuntu-dev-tools
is also a collection of scripts (like devscripts), but specific for
Ubuntu. It contains tools like update-maintainer, dgetlp, what-patch,
pbuilder-dist, etc.
- debhelper are scripts that perform common packaging tasks.
- dh-make can be used to create a template for your packaging.
- diff and patch
are used to create and apply patches, respectively. They are used
extensively in packaging because it is easier, cleaner, and more
efficient to represent small changes as patches rather than to have
multiple copies of a file.
- quilt
manages a series of patches by keeping track of the changes each of
them makes. They are logically organized as a stack, and you can apply,
un-apply, refresh them easily by traveling into the stack (push/pop).
This package completely integrates into the CDBS, allowing maintainers
using this new paradigm for their packaging scripts to benefit from the
comfort of quilt when editing their diff against upstream. The package
also provides some basic support for those not using CDBS.
- gnupg is a complete and free replacement for PGP used to digitally sign files (including packages).
- fakeroot simulates running a command with root privileges. This is useful for creating binary packages as a regular user.
- lintian and linda
dissect Debian packages and report bugs and Policy violations. They
contain automated checks for many aspects of Debian Policy as well as
for common errors. linda is not available from the hardy heron repositories, but is still available in previous releases repositories.
- pbuilder
constructs a chroot system and builds a package inside the chroot. It
is an ideal system to use to check that a package has correct build
dependencies and to build clean packages to be tested and distributed.
">
The Personal Builder: pbuilder
" lang="en">">
Using
pbuilder as a package builder allows you to build the package from
within a chroot environment. You can build binary packages without
using pbuilder, but you must have all the
build dependencies installed on your system first. However, pbuilder
allows the packager to check the build dependencies because the package
is built within a minimal Ubuntu installation, and the build dependencies are downloaded according to the debian/control file.
PbuilderHowto
is a comprehensive guide to almost anything you could wish to do with pbuilder.
A short overview:
- to create a pbuilder environment, run
sudo pbuilder create --distribution \
--othermirror "deb http://archive.ubuntu.com/ubuntu main restricted universe multiverse" - to build a package using pbuilder, run
sudo pbuilder build *.dsc - to update a pbuilder environment, run
sudo pbuilder update - use pbuilder-dist (of the ubuntu-dev-tools) to have several different pbuilder setups for different Ubuntu releases.
">
Basic Packaging
" lang="en">">
Two of the
problems that many novice packagers face are that there are multiple
ways of packaging, and there is more than one tool to do the job.
Package
development often requires installing many packages (especially -dev
packages containing headers and other common development files) that
are not part of a normal desktop Ubuntu installation. If you want to
avoid installing extra packages or would like to develop for a
different Ubuntu release (the development one, for instance) from what
you currently have, the use of a chroot environment is highly
recommended. A guide to setting up a chroot can be found at
DebootstrapChroot
.
">
We will go through two examples with the common build systems. We will use debhelper, the most common build system in Debian. It helps the packager by automating repetitive tasks. Then we will briefly cover the Common Debian Build System (CDBS), a more streamlined build system that uses debhelper.
Packaging From Scratch
" lang="en">">
Requirements: build-essential, automake, gnupg, lintian, fakeroot, pbuilder, debhelper and dh-make. In this example we will be using the GNU hello program as our example. You can download the source tarball from
ftp.gnu.org
. For the purposes of this example, we will be using the ~/hello/ directory.
mkdir ~/hello
cd ~/hello
wget http://ftp.gnu.org/gnu/hello/hello-2.1.1.tar.gzIf
you are packaging your own software, or the software is not available
as a tar.gz file, you can create the required .tar.gz from an unpacked
source directory with a command like the following:
tar czf hello-2.1.1.tar.gz hello-2.1.1For the purpose of this example, we will also compare our package (hello) to one that is already packaged in the Ubuntu repository (called hello-debhelper). For now, we will place it in the ubuntu directory so we can look at it later. To get the source package, make sure you have a "deb-src" line in your /etc/apt/sources.list file for the Main repository. Then, simply execute:
mkdir ubuntu
cd ubuntu
apt-get source hello-debhelper
cd ..Unlike
most apt-get commands, you do not need to have root privileges to get
the source package, because it is downloaded to the current directory.
In fact, it is recommended that you only use apt-get source as a
regular user, because then you can edit files in the source package
without needing root privileges. What the apt-get source command does is:
Download
the source package. A source package commonly contains a .dsc file
describing the package and giving md5sums for the source package, an
.orig.tar.gz file containing the source code from the author(s), and a
.diff.gz file containing the packaging (in the debian/ directory) and
patches applied against the source code. Untar the .orig.tar.gz file into the current directory. Apply the unzipped .diff.gz to the unpacked source directory. If you manually download the source package (.dsc, .orig.tar.gz, and .diff.gz files), you can unpack them in the same way apt-get source does by using dpkg-source as follows:
dpkg-source -x *.dscWe
want to recreate the above from scratch. The first thing you will need
to do is make a copy of the original (sometimes called "upstream")
tarball in the following format: _.orig.tar.gz.
This step does two things. First, it creates two copies of the source
code. If you accidentally change or delete the working copy you can use
the one you downloaded. Second, it is considered poor packaging
practice to change the original source tarball unless absolutely
necessary. See the section called “Common Mistakes” for reasons.
cp hello-2.1.1.tar.gz hello_2.1.1.orig.tar.gz
tar -xzvf hello_2.1.1.orig.tar.gzThe
underscore, "_", between the package name (hello) and the version
(2.1.1), as opposed to a hyphen, "-", is very important. The packaging
tools will look for a file with that exact name. If you get it wrong,
the result is that the tools will incorrectly assume that there is no
original source at all and the package will be built as a Debian native
package.
We now have a hello-2.1.1 directory containing the source files. Now we need to create the customary debian
directory where all the packaging information is stored, allowing us to
separate the packaging files from the application source files. We will
let dh_make do the work for us:
cd hello-2.1.1
dh_make -e your.maintainer@addressdh_make will then ask you a series of questions about your package:
Type of package: single binary, multiple binary, library, kernel module or cdbs?
[s/m/l/k/b] s
Maintainer name : Your Name
Email-Address : your.maintainer@address
Date : Thu, 6 Apr 2006 10:07:19 -0700
Package Name : hello
Version : 2.1.1
License : blank
Type of Package : Single
Hit to confirm: EnterOnly run dh_make
once. If you run it again after you do it the first time, it will not
work properly. If you want to change it or made a mistake, remove the
source directory and untar the upstream tarball afresh. Then you can
migrate into the source directory and try again.
Running dh_make creates the basic files needed in debian/ and many template files (.ex) that may be needed. The Hello
program is not very complicated, and as we have seen in the section
called “Packaging From Scratch”, packaging it does not require much
more than the basic files. Therefore, let us remove the .ex files:
cd debian
rm *.ex *.EXFor hello, you will also not need some of the files into the debian directory:
- README.Debian: the README file for specific Debian issues, not the program's README.
- dirs: Used by dh_installdirs to create needed directories.
- docs: Used by dh_installdocs to install program documentation.
- info: Used by dh_installinfo to install the info file.
Keep
in mind that for most packages, these files are required. For more
information on them, see the section called “dh_make example files”.
At this point, you should have only changelog, compat, control, copyright, and rules files in the debian directory.
">
changelog
" lang="en">">
The changelog
file is, as its name implies, a listing of the changes made in each
version. It has a specific format that gives the package name, version,
distribution, changes, and who made the changes at a given time. If you
have a GPG key, make sure to use the same name and email address in changelog as you have in your key. The following is a template changelog:
package (version) distribution; urgency=urgency
* change details
more change details
* even more change details
-- maintainer name [two spaces] dateThe format (especially of the date) is important. The date should be in RFC822 format, which can be obtained by using the command date -R. For convenience, the command dch may be used to edit changelog. It will update the date automatically.
Minor bullet points are indicated by a dash "-", while major points use an asterisk "*".
Here is a sample changelog file for hello:
hello (2.1.1-0ubuntu1) hardy; urgency=low
* New upstream release with lots of bug fixes.
-- Captain Packager Wed, 5 Apr 2006 22:38:49 -0700Notice
that the version has a -0ubuntu1 appended to it, this is the distro
revision, used so that the packaging can be updated (to fix bugs for
example) with new uploads within the same source release version.
Ubuntu
and Debian have slightly different package versioning schemes to avoid
conflicting packages with the same source version. If a Debian package
has been changed in Ubuntu, it has ubuntuX (where X is the Ubuntu
revision number) appended to the end of the Debian version. So if the
Debian hello 2.1.1-1 package was changed by Ubuntu, the version string
would be 2.1.1-1ubuntu1. If a package for the application does not
exist in Debian, then the Debian revision is 0 (e.g., 2.1.1-0ubuntu1).
Now look at the changelog for the Ubuntu source package that we downloaded earlier:
less ../../ubuntu/hello-debhelper-2.2/debian/changelogNotice that in this case the distribution is unstable (a Debian branch), because the Debian package has not been changed by Ubuntu. Remember to set the distribution to your target distribution release.
Consult
Debian changelog Policy
for more information.
">
control
" lang="en">">
The control file contains the information that the package manager (such as apt-get, synaptic, and adept) uses, build-time dependencies, maintainer information, and much more.
For the Ubuntu hello package, the control file looks something like:
Source: hello
Section: devel
Priority: optional
Maintainer: Ubuntu MOTU Developers
XSBC-Original-Maintainer: Captain Packager
Standards-Version: 3.7.3
Build-Depends: debhelper (>= 5)
Homepage: http://www.gnu.org/software/hello/
Package: hello
Architecture: any
Depends: ${shlibs:Depends}
Description: The classic greeting, and a good example
The GNU hello program produces a familiar, friendly greeting. It
allows non-programmers to use a classic computer science tool which
would otherwise be unavailable to them. . Seriously, though: this is
an example of how to do a Debian package. It is the Debian version of
the GNU Project's `hello world' program (which is itself an example
for the GNU Project).In
Ubuntu we set the Maintainer field to a general address because anyone
can change any package (this differs from Debian where changing
packages is usually restricted to an individual or a team).
Edit control using the information above (making sure to provide your information for the XSBC-Original-Maintainer field).
">
" lang="en">">
The first paragraph gives information about the source package. Let us go through each line:
- Source: This is the name of the source package.
- Section: The apt repositories are split up into sections for ease of browsing and categorization of software.
- Priority: This sets the importance of the package to users. It should be one of the following:
- Required
- packages that are essential for the system to work properly. If they
are removed it is highly likely that your system will break in an
unrecoverable way.
- Important
- minimal set of packages for a usable system. Removing these packages
will not produce an unrecoverable breakage of your system, but they are
generally considered important tools without which any Linux
installation would be incomplete. Note: This does not include things
like Emacs or even the X Window System.
- Standard - Somewhat self explanatory.
- Optional
- in essence this category is for non-required packages, or the bulk of
packages. However, these packages should not conflict with each other.
- Extra
- packages that may conflict with packages in one of the above
categories. Also used for specialized packages that would only be
useful to people who already know the purpose of the package.
- Maintainer: The name of the package maintainer and their email address.
- Standards-Version: The version of the
Debian Policy
to which the package adheres. An easy way to find the current version is apt-cache show debian-policy | grep Version .
- Build-Depends:
One of the most important fields and often the source of bugs, this
line lists the binary packages (with versions if necessary) that need
to be installed in order to create the binary package(s) from the
source package. Packages that are essential are required by build-essential and do not need to be included in the Build-Depends line. Note, that you don't need to list packages that are a part of build-essential. The list of build-essential packages can be found at /usr/share/doc/build-essential/list.
- Homepage: A URL where more information on the software can be found.
The
second paragraph is for the binary package that will be built from the
source. If multiple binary packages are built from the source package,
there should be one section for each one. Again, let us go through each line:
- Package: The name for the binary package. Many times for simple programs (such as hello), the source and binary packages' names are identical.
- Architecture: The architectures for which the binary package(s) will be built. Examples are:
- all - The source is not
architecture-dependent. Programs that use Python or other interpreted
languages would use this. The resulting binary package would end with _all.deb.
- any - The source is architecture-dependent and should compile on all the supported architectures. There will be a .deb file for each architecture (_i386.deb for instance)
- A
subset of architectures (i386, amd64, ppc, etc.) can be listed to
indicate that the source is architecture-dependent and does not work
for all architectures supported by Ubuntu.
- Depends: The list of packages that the binary package depends on for functionality. For hello, we see ${shlibs:Depends}, which is a variable that is used by dpkg-shlibdeps to add the shared library packages needed by the binaries to Depends:. See the dpkg-source(1) and dpkg-shlibdeps(1) man page for more information.
- Recommends: Used for packages that are highly recommended and usually are installed with the package. Some package managers, most notably aptitude, automatically install Recommended packages.
- Suggests: Used for packages that are similar or useful when this package is installed.
- Conflicts:
Used for packages that will conflict with this package. Both cannot be
installed at the same time. If one is being installed, the other will
be removed.
- Description:
Both short and long descriptions are used by package managers. Note
that there is one space at the beginning of each line in the long
description. More information on how to make a good description can be
found at
http://people.debian.org/~walters/descriptions.html
">
copyright
" lang="en">">
This file gives the copyright information. Generally, copyright information is found in the COPYING
file in the program's source directory. This file should include such
information as the names of the author and the packager, the URL from
which the source came, a Copyright line with the year and copyright
holder, and the text of the copyright itself. An example template would
be:
This package was debianized by {Your Name}
{Date}
It was downloaded from: {URL of webpage}
Upstream Author(s): {Name(s) and email address(es) of author(s)}
Copyright:
Copyright (C) {Year(s)} by {Author(s)} {Email address(es)}
License:
{Add licence text here. For GNU licences add the licence header
and a link to the appropriate file in /usr/share/common-licences.}
Packaging:
Copyright (C) {Year(s)} by {Your Name}
released under {the licence you choose for your packaging}As one can imagine, hello is released under the GPL license. In this case it is easiest to just copy the copyright file from the Ubuntu package:
cp ../../ubuntu/hello-debhelper-2.2/debian/copyright .Notice that the Ubuntu package's copyright includes a license statement for the manual. It is important that all the files in the source be covered by a license statement.
More information, caveats and tips are available in the
Copyright section
.
">
rules
" lang="en">">
The last file we need to look at is rules.
This does all the work for creating our package. It is a Makefile with
targets to compile and install the application, then create the .deb
file from the installed files. It also has a target to clean up all the
build files so you end up with just a source package again.
Here is a simplified version of the rules file created by dh-make:
package = hello
CC = gcc
CFLAGS = -g -Wall
ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O2
endif
#export DH_VERBOSE=1
clean:
dh_testdir
dh_clean
rm -f build
-$(MAKE) -i distclean
install: build
dh_clean
dh_installdirs
$(MAKE) prefix=$(CURDIR)/debian/$(package)/usr \
mandir=$(CURDIR)/debian/$(package)/usr/share/man \
infodir=$(CURDIR)/debian/$(package)/usr/share/info \
install
build:
./configure --prefix=/usr
$(MAKE) CC="$(CC)" CFLAGS="$(CFLAGS)"
touch build
binary-indep: install
# There are no architecture-independent files to be uploaded
# generated by this package. If there were any they would be
# made here.
binary-arch: install
dh_testdir -a
dh_testroot -a
dh_installdocs -a NEWS
dh_installchangelogs -a ChangeLog
dh_strip -a
dh_compress -a
dh_fixperms -a
dh_installdeb -a
dh_shlibdeps -a
dh_gencontrol -a
dh_md5sums -a
dh_builddeb -a
binary: binary-indep binary-arch
.PHONY: binary binary-arch binary-indep clean checkrootLet us go through this file in some detail. One of the first parts you will see is the declaration of some variables:
package = hello
CC = gcc
CFLAGS = -g -Wall
ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O2
endif
#export DH_VERBOSE=1This section sets the flags for the compiler and also handles the noopt options for debugging.
Now look at the build rule:
build:
./configure --prefix=/usr
$(MAKE) CC="$(CC)" CFLAGS="$(CFLAGS)"
touch buildThis rule runs ./configure with the proper prefix, runs make, and creates a build file that is a timestamp of the build to prevent erroneous multiple compilations.
The next rule is clean, which runs make -i distclean and removes the files that are made during the package building.
clean:
dh_testdir
dh_clean
rm -f build
-$(MAKE) -i distcleanNext we see an empty binary-indep
rule. Some packages create architecture-independent .debs if they do
not contain files that are specific to the processor. Most Python or
artwork packages would be examples of this, their packages end with
_all.deb.
hello
is a C programme so compiles to different code for each architecture,
the packages will end with _i386.deb etc. For these
architecture-dependent packages, binary-arch is used:
binary-arch: install
dh_testdir -a
dh_testroot -a
dh_installdocs -a NEWS
dh_installchangelogs -a ChangeLog
dh_strip -a
dh_compress -a
dh_fixperms -a
dh_installdeb -a
dh_shlibdeps -a
dh_gencontrol -a
dh_md5sums -a
dh_builddeb -aThis
is running a number of debhelper scripts which create our .deb
packages. dh_testdir and dh_testroot make some sanity checks.
dh_installdocs and dh_installchangelogs install files which you can
specify in *.doc and *.changelog files. dh_strip will take debugging
symbols out of the application files making them much smaller.
dh_compress runs gzip on some documentation files. dh_shlibdeps adds
library dependencies to the "Depends: ${shlibs:Depends}" field in
debian/control. Finally dh_builddeb builds our .deb file. You do not
have to worry too much about these scripts, they should create the
packages without problems.
There is one other file, compat
which just contains a version number for the debhelper scripts.
Occationally new versions of debhelper are released, the current
version is 6 so you should set compat to 6. If it is set to an older version then the debhelper scripts will behave slightly differently.
">
Building the Package
" lang="en">">
You are now ready to build the package. There is a simple command to do this.
debuildDebuild will first check that all the build-depends packages are installed, it will then use dpkg-buildpackage
to compile, install and build the .debs using the rules in
debian/rules. If that succeeds it will attempt to digitally sign the
packages with GPG, if it gives an error that it can not find your key
that means it has successfully compiled the .deb packages but you do
not have a GPG key with the same name, comment, and e-mail as you used
in debian/changelog. See
GnuPrivacyGuardHowto
for instructions on creating your key.
Your finished package should now be in the directory above your source. Have a look at it and install it.
cd ..
lesspipe *deb
sudo dpkg --install *deb">
Building the Source Package
" lang="en">">
Now that we have gone through the files in the debian directory for hello
in detail, we can build the source (and binary) packages. First let us
move into the root of the extracted source then we build the source
package using debuild:
debuild -SThe -S flag tells debuild to build a source package using another script dpkg-buildpackage and fakeroot to allow us to have fake root privileges when making the package. It will take the .orig.tar.gz file and produce a .diff.gz (the difference between the original tarball from the author and the directory we have created, debian/ and its contents) and a .dsc file that has the description and md5sums for the source package. The .dsc and *_source.changes (used for uploading the source package) files are signed using your GPG key.
If you do not have a gpg key set up you will get an error from debuild. You can either set up a gpg key or use the -us -uc keys with debuild to turn off signing. However, you will not be able to have your packages uploaded to Ubuntu without signing them. To make sure debuild finds the right gpg key you should set the DEBFULLNAME and DEBEMAIL environment variables (in your ~/.bashrc for instance) to the name and email address you use for your gpg key and in the debian/changelog.Some people have reported that they were unable to get debuild to find their gpg key properly, even after setting the above environment variables. To get around this you can give debuild the -k flag where is your gpg key ID.
To check the package builds in a clean environement we can also build the binary package with pbuilder:
sudo pbuilder build ../*.dscUsing pbuilder to build the binary packages is very important. It ensures that the build dependencies are correct, because pbuilder provides only a minimal environment, so all the build-time dependencies are determined by the control file.
We can check the source package for common mistakes using lintian:
cd ..
lintian -Ivi *.dsc
">
Requirements for new Ubuntu packages
When
a source package is uploaded to Ubuntu which does not yet exist in the
archive, or builds a new binary package, it will be held in the
NEW queue
and has to be reviewed by an
Ubuntu archive team
member.
Packaging
- Most importantly: see
copyright and licensing information
below.
- The
source and binary packages should have a sane name: neither they should
clutter the namespace (such as "editor") nor should they have an
entirely nonsensical name (such as "new-stuff-manager"). - debian/control and debian/rules should build packages with the right Architecture:, Build-Depends[-Indep]:, and rules target (binary-arch vs. binary-indep).
- Maintainer and init scripts should not excessively mess up the system.
- A more comprehensive list of package checks is available from the
Code Review
page.
Other
Packaging With CDBS
" lang="en">">
CDBS is a
set of Makefile includes that uses debhelper to make building and
maintaining Debian packages even easier. It uses advanced features of
Makefiles to abstract the build process, so rules files end up primarily as a series of include statements. It has many advantages:
- It produces a short, readable, and efficient debian/rules
- It automates debhelper use for you, so you do not have to worry about repetitive tasks
- It helps you focus on more important packaging problems, because it helps without limiting customization
- Its classes have been well tested, so you can avoid dirty hacks to solve common problems
- Switching to CDBS is easy
- It is extendable
However
if your package has an oddity about how it is built you may need to
tackle some of the Makefile syntax to extend CDBS and tell it what is
needed.
Using
CDBS for Ubuntu packages is very easy, if the software you are
packaging can be configured and built using the GNU autoconf tools (the
"configure-make-make install" idiom). After adding cdbs to the Build-Depends in debian/control, a basic debian/rules file using CDBS can fit in 2 lines. For a simple C/C++ application with no extra rules, such as hello, debian/rules can look like this :
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/autotools.mkThat is all you need to build the program! CDBS handles installing and cleaning. You can then use the .install and .info files to tune your package with the usual debhelper functions in the various sections for debian/rules.
Sometimes
the upstream author has hardwired non-standard defaults into the
autoconf scripts. For example, a package may place man pages in /usr/man/. In this case, you can specify the correct path by specifying:
DEB_CONFIGURE_MANDIR=/usr/share/manAnother situation frequently seen in configure
scripts is that you need to specify certain optional configuration
options provided by the software author. This is handled by putting
this option in the variable, for example:
DEB_CONFIGURE_EXTRA_FLAGS = --enable-graphics --with-gsl=/usrHere is the list of standard configure options that are always passed to configure:
--prefix=$(DEB_CONFIGURE_PREFIX)
--includedir=$(DEB_CONFIGURE_INCLUDEDIR)
--mandir=$(DEB_CONFIGURE_MANDIR)
--infodir=$(DEB_CONFIGURE_INFODIR)
--sysconfdir=$(DEB_CONFIGURE_SYSCONFDIR)
--localstatedir=$(DEB_CONFIGURE_LOCALSTATEDIR)
--libexecdir=$(DEB_CONFIGURE_LIBEXECDIR)" lang="en">">
CDBS mostly works by including .mk Makefiles in debian/rules. The cdbs package provides such files in /usr/share/cdbs/1/ that allow you to do quite a lot of packaging tasks. Other packages, such as quilt,
add modules to CDBS and can be used as Build-Depends. Note that you can
also use your own CDBS rules and include them in the package. The most
useful modules included with the cdbs package are:
- rules/debhelper.mk: Calls debhelper in all required sections
- rules/dpatch.mk: Allows you to use dpatch to ease patching the source. Must be included before any other rule.
- rules/simple-patchsys.mk: Provides a very easy way to patch the source
- rules/tarball.mk: Allows you to build packages using the compressed tarball in the package
- class/autotools.mk: Calls autotools in all required sections
- class/gnome.mk: Builds GNOME programs (requires the proper Build-Depends in debian/control)
- class/kde.mk: Builds KDE programs (requires the proper Build-Depends in debian/control)
- class/xfce.mk: Build Xfce4 programs (requires the proper Build-Depends in debian/control)
- class/python-distutils.mk: Facilitates packaging Python programs
">
It may happen that you need to patch files belonging to the autoconf system. In such cases, you typically need to run aclocal, automake and autoconf
after the patch has been applied. CDBS has options to assist you in
this situation. It will run patch first, then rebuild the autotools,
and finally run configure "et al." Here is an example, where versions
1.10 of autoconf and automake are chosen:
include /usr/share/cdbs/1/rules/dpatch.mk
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/autotools.mk
DEB_AUTO_UPDATE_ACLOCAL = 1.10 -I ./config
DEB_AUTO_UPDATE_LIBTOOL = pre
DEB_AUTO_UPDATE_AUTOMAKE = 1.10 --foreign --add-missing --copy
DEB_AUTO_UPDATE_AUTOCONF = 1.10The
DEB_AUTO_UPDATE_LIBTOOL variable can take the values "pre" or "post",
depending on how you want libtool to be run. Notice that (curiously)
aclocal is only invoked if aclocal.m4 is already present in the top level directory.
A
word of warning is in place at this point: Some packagers do not trust
that the autoconf system can be generated correctly on a foreign build
system.
" lang="en">">
CDBS runs
the debhelper scripts after the package has been compiled and
installed. Sometimes you may need to modify the behaviour of certain
debhelper scripts. A bunch of variables are available for this purpose:
debhelper script
CSBS variable
dh_builddeb
DEB_BUILD_DEB_ARGS
dh_compress
DEB_COMPRESS_ARGS
dh_fixperms
DEB_FIXPERMS_ARGS
dh_gencontrol
DEB_GENCONTROL_ARGS
dh_installcatalog
DEB_INSTALLCATALOGS_ARGS
dh_installchangelogs
DEB_INSTALLCHANGELOGS_ARGS
dh_installdebconf
DEB_INSTALLDEBCONF_ARGS
dh_installdeb
DEB_INSTALL_DEB_ARGS
dh_installemacsen
DEB_INSTALLEMACSEN_ARGS
dh_installinit
DEB_INSTALLINIT_ARGS
dh_installlogcheck
DEB_INSTALLLOGCHECK_ARGS
dh_installlogrotate
DEB_INSTALLLOGROTATE_ARGS
dh_installmime
DEB_INSTALLMIME_ARGS
dh_installpam
DEB_INSTALLPAM_ARGS
dh_installudev
DEB_INSTALLUDEV_ARGS
dh_install
DEB_INSTALL_ARGS
dh_makeshlibs
DEB_MAKESHLIBS_ARGS
dh_md5syms
DEB_MD5SUMS_ARGS
dh_perl
DEB_PERL_ARGS
dh_shlibdeps
DEB_SHLIBDEPS_ARGS
dh_strip
DEB_STRIP_ARGS
">
See
the manpages of the individual debhelper scripts to see what options
are available. One thing that is commonly needed is to exclude files
from the action of certain debhelper scripts. For example, you may
arrange that a certain file maintains the permissions with which it was
installed, and not become modified by the dh_fixperms script:
DEB_FIXPERMS_EXCLUDE = /usr/sbin/suid-program" lang="en">">
The complete list of CDBS' exclude variables is:
DEB_COMPRESS_EXCLUDE
DEB_FIXPERMS_EXCLUDE
DEB_CLEAN_EXCLUDE
DEB_DH_ALWAYS_EXCLUDE
DEB_STRIP_EXCLUDE
">
本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/52215/showart_1758044.html |
|
免费注册
发表于 2008-12-29 10:35