dpkg
and apt
into believing that some package is installed even though it's only an empty shell. This allows satisfying dependencies on a package when the corresponding software was installed outside the scope of the packaging system. Such a method works, but it should still be avoided whenever possible, since there's no guarantee that the manually installed software behaves exactly like the corresponding package would and other packages depending on it would not work properly.
equivs-control
and equivs-build
commands (in the equivs package). The equivs-control file
command creates a Debian package header file that should be edited to contain the name of the expected package, its version number, the name of the maintainer, its dependencies, and its description. Other fields without a default value are optional and can be deleted. The Copyright
, Changelog
, Readme
and Extra-Files
fields are not standard fields in Debian packages; they only make sense within the scope of equivs-build
, and they will not be kept in the headers of the generated package.
Example 15.2. Header file of the libxml-libxml-perl fake package
Section: perl Priority: optional Standards-Version: 3.8.4 Package: libxml-libxml-perl Version: 1.57-1 Maintainer: Raphael Hertzog <hertzog@debian.org> Depends: libxml2 (>= 2.6.6) Architecture: all Description: Fake package - module manually installed in site_perl This is a fake package to let the packaging system believe that this Debian package is installed. . In fact, the package is not installed since a newer version of the module has been manually compiled & installed in the site_perl directory.
equivs-build file
command. Voilà: the package is created in the current directory and it can be handled like any other Debian package would.
falcot-data-1.0
directory to contain the target source package. The package will logically, be named falcot-data
and bear the 1.0
version number. The administrator then places the document files in a data
subdirectory. Then they invoke the dh_make
command (from the dh-make package) to add files required by the package generation process, which will all be stored in a debian
subdirectory:
$
cd falcot-data-1.0
$
dh_make --native
Type of package: single binary, indep binary, multiple binary, library, kernel module, kernel patch or cdbs? [s/i/m/l/k/n/b]
i
Maintainer name : Raphael Hertzog Email-Address : hertzog@debian.org Date : Mon, 11 Apr 2011 15:11:36 +0200 Package Name : falcot-data Version : 1.0 License : blank Usind dpatch : no Type of Package : Independent Hit <enter> to confirm: Currently there is no top level Makefile. This may require additional tuning. Done. Please edit the files in the debian/ subdirectory now. You should also check that the falcot-data Makefiles install into $DESTDIR and not in / . $
Architecture: any
). indep binary acts as a counterpart, and leads to a single binary package that is not dependent on the target architecture (Architecture: all
). In this case, the latter choice is more relevant since the package only contains documents and no binary programs, so it can be used similarly on computers of all architectures.
dh_make
command created a debian
subdirectory with many files. Some are required, in particular rules
, control
, changelog
and copyright
. Files with the .ex
extension are example files that can used by modifying them (and removing the extension) when appropriate. When they are not needed, removing them is recommended. The compat
file should be kept, since it is required for the correct functioning of the debhelper suite of programs (all beginning with the dh_
prefix) used at various stages of the package build process.
copyright
file must contain information about the authors of the documents included in the package, and the related license. In our case, these are internal documents and their use is restricted to within the Falcot Corp company. The default changelog
file is generally appropriate; replacing the “Initial release” with a more verbose explanation and changing the distribution from unstable
to internal
is enough. The control file
was also updated: the section has been changed to misc and the Homepage
, Vcs-Git
and Vcs-Browser
fields were removed. The Depends
fields was completed with iceweasel | www-browser
so as to ensure the availability of a web browser able to display the documents in the package.
Example 15.3. The control
file
Source: falcot-data Section: misc Priority: optional Maintainer: Raphael Hertzog <hertzog@debian.org> Build-Depends: debhelper (>= 7.0.50~) Standards-Version: 3.8.4 Package: falcot-data Architecture: all Depends: iceweasel | www-browser, ${misc:Depends} Description: Internal Falcot Corp Documentation This package provides several documents describing the internal structure at Falcot Corp. This includes: - organization diagram - contacts for each department. . These documents MUST NOT leave the company. Their use is INTERNAL ONLY.
Example 15.4. The changelog
file
falcot-data (1.0) internal; urgency=low * Initial Release. * Let's start with few documents: - internal company structure; - contacts for each department. -- Raphael Hertzog <hertzog@debian.org> Mon, 11 Apr 2011 20:46:33 +0200
Example 15.5. The copyright
file
This work was packaged for Debian by Raphael Hertzog <hertzog@debian.org> on Mon, 11 Apr 2011 20:46:33 +0200 Copyright: Copyright (C) 2004-2011 Falcot Corp License: All rights reserved.
rules
file usually contains a set of rules used to configure, build and install the software in a dedicated subdirectory (named after the generated binary package). The contents of this subdirectory is then archived within the Debian package as if it were the root of the filesystem. In our case, files will be installed in the debian/falcot-data/usr/share/falcot-data/
subdirectory, so that installing the generated package will deploy the files under /usr/share/falcot-data/
. The rules
file is used as a Makefile
, with a few standard targets (including clean
and binary
, used respectively to clean the source directory and generate the binary package).
debhelper
tool. Such is the case for files generated by dh_make
. To install our files, we simply configure the behavior of the dh_install
command by creating the following debian/falcot-data.install
file:
data/* usr/share/falcot-data/
debian/menu.ex
without its extension and editing it as follows:
Example 15.6. The menu
file
?package(falcot-data):needs=X11|wm section=Help\ title="Internal Falcot Corp Documentation" \ command="/usr/bin/x-www-browser /usr/share/falcot-data/index.html" ?package(falcot-data):needs=text section=Help\ title="Internal Falcot Corp Documentation" \ command="/usr/bin/www-browser /usr/share/falcot-data/index.html"
needs
field, when set to X11|wm
indicates that this entry only makes sense in a graphical interface. It will therefore only be integrated into the menus of the graphical (X11) applications and window managers (hence the wm
). The section
field states where in the menu the entry should be displayed. In our case, the entry will be in the Help menu. The title
field contains the text that will be displayed in the menu. Finally, the command
field describes the command to run when the user selects the menu entry.
debian/menu
file is enough to enable the menu in the package, since the dh_installmenu
command is automatically invoked by dh
during the package build process.
dpkg-buildpackage -us -uc
command from within the falcot-data-1.0
directory.