Status: Just notes so far
Last changed: Sunday 2014-03-23 10:34 UTC
Software evolves over time. Debian has a lot of software, some of which is related to each other, some of which depends on other software, some of which is redundant etc. A common problem is how to acquire a newer version of some particular piece of software without making the current system freak out in some way or the other... And then of course, we want bugs to get fixed and security related flaws to get fixed as well. What we also want is for the whole process to be as consistent and less time consuming as possible. It would also be nice if we could install software without the need for having an PhD or read a thousand pages of manuals before doing so. The process should be reversal i.e. removing software should be possible as well after it had been installed. We also want to have tools for monitoring and providing us with information about all the software installed or not installed but available for installing. And what about the means for distributing the software? How does this work? What is a software packages life-cycle? And by the way, what is a "software package" also known as .deb anyway? What can I do to help? What is a debian developers job?...
Clearly, I could go on and on but then it is easier to say that the answer to all those questions can be found below. Whether it is about packaging software, providing bug fixes upstream, reporting bugs, taking good care of Debian's free software guidelines, using the tools to carry out all actions related to managing software packages, etc.
Table of Contents
APT (Advanced Packaging Tool)
APT the Mechanism
APT relies on the concept of repositories in order to find software
and resolve dependencies. For APT the library and APT the toolset, a
repository is a directory containing packages along with an index
file. This can be specified as a networked or local (CDROM, HDD, USB
stick, etc.) location. As of now, October 2008, the Debian project
keeps a central repository of over 25000 software packages ready for
download and installation.
APT the Library
This subsection is about APT (Advanced Packaging Tool) the library as
apt-* (set of tools) to make use APT the library.
/etc/apt has the APT configuration folders and files.
the APT configuration query program.
apt-config dump shows the
/etc/apt/sources.list, locations to fetch packages from.
/etc/apt/sources.list.d/, additional source list fragments.
/etc/apt/apt.conf, APT configuration file.
/etc/apt/apt.conf.d/, APT configuration file fragments.
/etc/apt/preferences, version preferences file. This is where we
would specify pinning, i.e. a preference to get certain packages
from a separate source location than the one specified in
/etc/apt/sources.list or from a different release version than
the one installed.
/var/cache/apt/archives/, storage area for retrieved package files.
/var/cache/apt/archives/partial/, storage area for package files in
/var/lib/apt/lists/, storage area for state information for each
package resource specified in
/var/lib/apt/lists/partial/, storage area for state information in
Apt vs Aptitude
aptitude remove dependencies of software installed by
- No. It must be installed by
aptitude in order to remove the
- Can there consistency problems arise by using both?
- No, that is a myth. However, in case we had used
apt-get in the
past and now we want to switch to
aptitude... well, no problem,
we can start using
aptitude instead of
aptitude will not
remove dependencies installed by
apt-get. We will need
to remove those. From here on out, however, we can use
install and administer all of our packages.
Nice things about Aptitude
- Human-readable logs in
/var/logs/aptitude.log. Those who have ever
tried to see which packages have been installed/removed/etc in
dpkg.log probably know what I am talking about.
aptitude search will list packages as well as their status,
whether installed or not.
Generally, we need to know that there is
aptitude, a single tool, and
that there is the whole set of
From my point of view
apt-* is really advanced, in the sense that it
can do a lot more than just performing the most commonly used options
provided by APT (Advanced Packaging Tool). It is a set of tools for
both, users and developers, novice and advanced. The downside however
is that it is a set of tools and therefore it makes things harder for
people to understand and use it to its full potential.
aptitude on the other side presents the more commonly used options of
APT (Advanced Packaging Tool) and most importantly is just a single
tool. As ever, there is no better, it is all about situation, skillets
and personal likings etc.
aptitude lacks some of the power that the whole
apt-* set of tools
provide. For example, aptitude does not have equivalents of these
rdepends. Also, there is
aptitude equivalent of
- aptitude-create-state-bundle produces a compressed archive storing
the files that are required to replicate the current package
- aptitude-run-state-bundle unpacks the given aptitude state bundle
created by aptitude-create-state-bundle(1) to a temporary
directory, invokes <program> on it with the supplied arguments,
and removes the temporary directory afterwards. If <program> is
not supplied, it defaults to aptitude(8).
This section is about how to create Debian packages (also known as dot
.debs). Furthermore, it provides an insight on the
works a Debian Developer also known as Debian Maintainer does in order
to provide the community with up to date software.
There are many things aside from packaging new software for Debian but
packaging is certainly at the core of things the community does in
order to deliver one of the best (if not the best) operating system
In essence, packaging makes sure that everyone using Debian gets
free software delivered onto his computer with practically no effort
at all i.e.
apt-get update && apt-get upgrade respectively
update && aptitude full-upgrade does the trick. This way the main
effort behind packaging becomes invisible to any Debian user i.e.
instead of making sure (by running time consuming tests etc.) the yet
to be installed code/software integrates smoothly into our existing,
yet up and running Debian system, all the user has to do is to run the
afore mentioned commands.
Also, what most novices seem to overlook sometimes, one of the package
maintainers duties is to make sure that only free software goes into
packages. This way the user can be certain of getting a system
consisting of nothing but FLOSS (Free/Libre Open Source Software)...
I am talking about freedom ladies and gentlemen!
So, packaging really is one of the main pillars of our community
effort to steadily improve a yet already world-class operating system
since it saves us all a lot of time, provides us with pre-tested code
and last but not least ensures we all remain with free software only.
With this subsection, I am going to provide a pretty much straight
forward tutorial for packaging software for Debian. I will mention
what is mandatory and also add a few hints for good practices. Also,
with the information provides here anyone will finally be able to
package software the way any official Debian developer does on a daily
basis. Furthermore, I am going to talk about non-technical matters
with regards to packaging as well because there is a whole lot more
than just the technical aspect to packaging software for Debian.
Whoever wants to start packaging software must know this. It is about
all the basics concerning the mechanism of the package management
system called APT (Advanced Packaging Tool) and related things. If
this knowledge is already know (are you sure?) then one might proceed
with a more specific, debian developer intended, manual.
For those who would rather skip all this stuff... well, that would
mean not just skipping the basics but also not to care
about what Debian really is which is of course unacceptable.
Fortunately, the Debian new maintainer process ensures that only
people who are really skilled, seriously determined with a long-term
goal in mind, and which have a great attitude about the philosophy
behind Debian are allowed to become official Debian developers —
sounds a bit though but then it simply ensures a state of the art OS
plus even more importantly, this way it saves a lot of folks (you/us)
a lot of time and troubles — I think there simply is no other way to
ensure a certain quality... Also, before I forget, I do have a
dedicated section which tells about common tools most probably needed
in the process in maintaining software for Debian.
Good to know
This section is about miscellaneous subjects with regards to Debian
BTS (Bug Tracking System)
Please go here for more information.
Please go here.
What are so-called snapshots? They are available here.
What are so-called backports? They are available here and here.
Maintaining your Debian Repository
This is a GNU Emacs package i.e. GNU Emacs capabilities towards Debian
in order to carry out a variety of tasks focusing on development and
maintaining software and its related parts with DebianGNU/*. However,
this information is only of interest to folks using both —
DebianGNU/* and GNU Emacs.