Building a deb Package. Check source freedom Some of these tutorials may refer to nonfree software.
Make sure to check the freedom of the source code or application before following any external tutorial. To handle packages, you need to install some programs: sudo apt-get install debhelper dh-make dpkg-dev Downloading and Extracting First, check if the program is free! Then, if it is or if there is not enough information on the program's website, download the program you want to build: wget or wget Extract the program source code from the archive: tar -xzf program.tar.gz tar -xjf program.tar.bz2 Generate "debian" Hierarchy You may want to keep your full name and email address from package to package.
Export DEBFULLNAME="Joe Black" export DEBEMAIL="joe.black@domain.ext" cd inside the extracted folder: cd program Check if the program is free! Run debhelper: dh_make Remove unneeded files: cd debian rm unneeded-files To convert your package to "quilt v3": mkdir -p source echo "3.0 (quilt)" >source/format. Debian Policy Manual - Package maintainer scripts and installation procedure. [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ] 6.1 Introduction to package maintainer scripts It is possible to supply scripts as part of a package which the package management system will run for you when your package is installed, upgraded or removed.
These scripts are the control information files preinst, postinst, prerm and postrm. They must be proper executable files; if they are scripts (which is recommended), they must start with the usual #! Debian Enhancement Proposals. Cdbs-presentation.pdf.
Debian Maintainer Tools. DebianMentorsFaq. This FAQ is intended to head off the standard set of questions asked by a large proportion of new posters to the debian-mentors mailing list.
There are four sections: General questions, about the list, Debian, and whatever else doesn't fit in another section. Packaging, issues relating to creating and maintaining Debian packages. Sponsored packages, all about the purpose and process of package sponsorship. For sponsors, info for developers sponsoring or considering sponsoring a package or two. If in doubt, just read the whole thing. General questions What is the debian-mentors mailing list for?
Debian-mentors is for the mentoring of new and prospective debian developers. In short, we aim to be the "softer, gentler" Debian development mailing list. One of the most common uses for the list is to attempt to get a sponsor for a piece of software you've packaged (or are intending to package). Things that aren't really appropriate for -mentors:
Python as deb. Php as deb. Java packaging and make systems. Chapter 2. Debian package management. The newbie Debian system administrator should stay with the stable release of Debian while applying only security updates.
I mean that some of the following valid actions are better avoided, as a precaution, until you understand the Debian system very well. Here are some reminders. Do not include testing or unstable in "/etc/apt/sources.list". Do not mix standard Debian with other non-Debian archives such as Ubuntu in "/etc/apt/sources.list". Do not create "/etc/apt/preferences". The non-compatible effects caused by above actions to the Debian package management system may leave your system unusable. The serious Debian system administrator who runs mission critical servers, should use extra precautions.
Do not install any packages including security updates from Debian without thoroughly testing them with your particular configuration under safe conditions. Let's look into the Debian archive from a system user's perspective.
Tutorials .. all great, and to the point. Using quilt for packaging. Work with source packages. Deb build & dhmake. Fpm. Chapter 5. Managing Packages. This chapter contains information related to creating, uploading, maintaining, and porting packages.
If you want to create a new package for the Debian distribution, you should first check the Work-Needing and Prospective Packages (WNPP) list. Checking the WNPP list ensures that no one is already working on packaging that software, and that effort is not duplicated. Read the WNPP web pages for more information. Assuming no one else is already working on your prospective package, you must then submit a bug report (Section 7.1, “Bug reporting”) against the pseudo-package wnpp describing your plan to create a new package, including, but not limiting yourself to, the description of the package (so that others can review it), the license of the prospective package, and the current URL where it can be downloaded from.
You should set the subject of the bug to ITP: foo -- short description, substituting the name of the new package for foo. 5.2. . * New upstream release.