TODO: Patch files do not record permissions of files and thus modified permissions are not stored in the source package. This warning reminds you of
that fact.

Segons el manual:

$ man dpkg-source
...
WARNINGS AND ERRORS
no source format specified in debian/source/format
The file debian/source/format should always exist and indicate the desired source format. For backwards compatibility, format "1.0" is assumed
when the file doesn't exist but you should not rely on this: at some point in the future dpkg-source will be modified to fail when that file
doesn't exist.
The rationale is that format "1.0" is no longer the recommended format, you should usually pick one of the newer formats ("3.0 (quilt)", "3.0
(native)") but dpkg-source will not do this automatically for you. If you want to continue using the old format, you should be explicit about it
and put "1.0" in debian/source/format.
the diff modifies the following upstream files
When using source format "1.0" it is usually a bad idea to modify upstream files directly as the changes end up hidden and mostly undocumented in
the .diff.gz file. Instead you should store your changes as patches in the debian directory and apply them at build-time. To avoid this complexity
you can also use the format "3.0 (quilt)" that offers this natively.
cannot represent change to file
Changes to upstream sources are usually stored with patch files, but not all changes can be represented with patches: they can only alter the con‐
tent of plain text files. If you try replacing a file with something of a different type (for example replacing a plain file with a symlink or a
directory), you will get this error message.
newly created empty file file will not be represented in diff
Empty files can't be created with patch files. Thus this change is not recorded in the source package and you are warned about it.
executable mode perms of file will not be represented in diff
special mode perms of file will not be represented in diff
Patch files do not record permissions of files and thus modified permissions are not stored in the source package. This warning reminds you of
that fact.

-rgain-root-command
When dpkg-buildpackage needs to execute part of the build process as root, it prefixes the command it executes with gain-root-command
if one has been specified. Otherwise, if none has been specified, fakeroot will be used by default, if the command is present.
gain-root-command should start with the name of a program on the PATH and will get as arguments the name of the real command to run and
the arguments it should take. gain-root-command can include parameters (they must be space-separated) but no shell metacharacters.
gain-root-command might typically be fakeroot, sudo, super or really. su is not suitable, since it can only invoke the user's shell
with -c instead of passing arguments individually to the command to be run.

TODO:

Segons el manual:

$ man dpkg-buildpackage
...
NAME
dpkg-buildpackage - build binary or source packages from sources
DESCRIPTION
dpkg-buildpackage is a program that automates the process of building a Debian package. It consists of the following steps:

It prepares the build environment by setting various environment variables (see ENVIRONMENT) and calls dpkg-source --before-build (unless -T or --target has been used).

It checks that the build-dependencies and build-conflicts are satisfied (unless -d is specified).

If a specific target has been selected with the -T or --target option, it calls that target and stops here. Otherwise it calls fakeroot debian/rules clean to clean the build-tree (unless -nc is specified).

It calls dpkg-source -b to generate the source package (unless a binary-only build has been requested with -b, -B or -A).

It calls debian/rules build followed by fakeroot debian/rules binary-target (unless a source-only build has been requested with -S). Note that binary-target is either binary (default case, or if -b is specified) or binary-arch (if -B is specified) or binary-indep (if -A is specified).

It calls gpg to sign the .dsc file (if any, unless -us is specified).

It calls dpkg-genchanges to generate a .changes file. Many dpkg-buildpackage options are forwarded to dpkg-genchanges.

It calls gpg to sign the .changes file (unless -uc is specified).

If -tc is specified, it will call fakeroot debian/rules clean again. Finally it calls dpkg-source --after-build.

dpkg-parsechangelog

dpkg-gensymbols

dpkg-name

dpkg-vendor

dpkg-distaddfile

dpkg-shlibdeps

dpkg-scanpackages

dpkg-checkbuilddeps

dpkg-scansources

dpkg-gencontrol

Serveix per a generar el fitxer de control d'un paquet binari a partir d'un paquet font.

Del manual:

$ mandpkg-gencontrol
dpkg-gencontrol reads information from an unpacked Debian source tree and generates a
binary package control file (which defaults to debian/tmp/DEBIAN/control); during this
process it will simplify the relation fields.
Thus Pre-Depends, Depends, Recommends and Suggests are simplified in this order by removing
dependencies which are known to be true according to the stronger dependencies already
parsed. It will also remove any self-dependency (in fact it will remove any dependency
which evaluates to true given the current version of the package as installed). Logically
it keeps the intersection of multiple dependencies on the same package. The order of depen‐
dencies is preserved as best as possible: if any dependency must be discarded due to
another dependency appearing further in the field, the superseding dependency will take the
place of the discarded one.
The other relation fields (Enhances, Conflicts, Breaks, Replaces and Provides) are also
simplified individually by computing the union of the various dependencies when a package
is listed multiple times in the field.
dpkg-gencontrol also adds an entry for the binary package to debian/files.
OPTIONS
-vversion
Sets the version number of the binary package which will be generated.
-Vname=value
Set an output substitution variable. See deb-substvars(5) for discussion of output
substitution.
-Tsubstvarsfile
Read substitution variables in substvarsfile; the default is debian/substvars.

Manual

$ man 7 debconf
NAME
debconf - Debian package configuration system
DESCRIPTION
Debconf is a configuration system for Debian packages. There is a rarely-used command named debconf,
documented in debconf(1)
Debconf provides a consistent interface for configuring packages, allowing you to choose from several
user interface frontends. It supports preconfiguring packages
before they are installed, which allows large installs and upgrades to ask you for all the necessary
information up front, and then go do the work while you do some‐
thing else. It lets you, if you're in a hurry, skip over less important questions and information while
installing a package (and revisit it later).
Preconfiguring packages
Debconf can configure packages before they are even installed onto your system. This is useful because
it lets all the questions the packages are going to ask be
asked at the beginning of an install, so the rest of the install can proceed while you are away getting a
cup of coffee.
If you use apt (version 0.5 or above), and you have apt-utils installed, each package apt installs will
be automatically preconfigured. This is controlled via
/etc/apt/apt.conf.d/70debconf
Sometimes you might want to preconfigure a package by hand, when you're not installing it with apt. You
can use dpkg-preconfigure(8) to do that, just pass it the
filenames of the packages you want to preconfigure. You will need apt-utils installed for that to work.
Reconfiguring packages
Suppose you installed the package, and answered debconf's questions, but now that you've used it awhile,
you realize you want to go back and change some of your answers. In the past, reinstalling a package
was often the thing to do when you got in this situation, but when you reinstall the package, debconf seems
to remember you have answered the questions, and doesn't ask them again (this is a feature).
Luckily, debconf makes it easy to reconfigure any package that uses it. Suppose you want to reconfigure
debconf itself. Just run, as root:
dpkg-reconfigure debconf
This will ask all the questions you saw when debconf was first installed. It may ask you other questions
as well, since it asks even low priority questions that may
have been skipped when the package was installed. You can use it on any other package that uses debconf,
as well.

SETTITLE: This sets the title to the short description of the template for the specified question. The template should be of type title. The advantage this has over the TITLE command is that it allows for titles to be stored in the same place as the rest of the debconf questions, and allows them to be translated.

INPUT priority question: priority indica la prioritat. Ask debconf to prepare to display a question to the user. The question is not actually displayed until a GO command is issued; this lets several INPUT commands be given in series, to build up a set of questions, which might all be asked on a single screen.

GO

CLEAR

BEGINBLOCK

ENDBLOCK

STOP

GET

SET

RESET

SUBST

FGET

FSET

METAGET

REGISTER

UNREGISTER

PURGE

GO
Tells debconf to display the accumulated set of questions (from INPUT commands) to the user.

If the backup capability is supported and the user indicates they want to back up a step, debconf
replies with code 30.

CLEAR Clears the accumulated set of questions (from INPUT commands) without displaying them.

BEGINBLOCK

ENDBLOCK
Some debconf frontends can display a number of questions to the user at once. Maybe in the future a
frontend will even be able to group these questions into blocks on screen. BEGINBLOCK and ENDBLOCK
can be placed around a set of INPUT commands to indicate blocks of questions (and blocks can even be
nested). Since no debconf frontend is so sophisticated yet, these commands are ignored for now.

STOP This command tells debconf that you're done talking to it. Often debconf can detect termination of
your program and this command is not necessary.

GET question
After using INPUT and GO to display a question, you can use this command to get the value the user
entered. The value is returned in the extended result code.

SET question value
This sets the value of a question, and it can be used to override the default value with something
your program calculates on the fly.

RESET question
This resets the question to its default value (as is specified in the 'Default' field of its tem‐
plate).

SUBST question key value
Questions can have substitutions embedded in their 'Description' and 'Choices' fields (use of substi‐
tutions in 'Choices' fields is a bit of a hack though; a better mechanism will eventually be devel‐
oped). These substitutions look like "${key}". When the question is displayed, the substitutions are
replaced with their values. This command can be used to set the value of a substitution. This is use‐
ful if you need to display some message to the user that you can't hard-code in the templates file.

Do not try to use SUBST to change the default value of a question; it won't work since there is a SET
command explicitly for that purpose.

FGET question flag
Questions can have flags associated with them. The flags can have a value of "true" or "false". This
command returns the value of a flag.

FSET question flag value
This sets the value of a question's flag. The value must be either "true" or "false".

One common flag is the "seen" flag. It is normally only set if a user has already seen a question.
Debconf usually only displays questions to users if they have the seen flag set to "false" (or if it
is reconfiguring a package). Sometimes you want the user to see a question again -- in these cases
you can set the seen flag to false to force debconf to redisplay it.

METAGET question field
This returns the value of any field of a question's associated template (the Description, for exam‐
ple).

REGISTER template question
This creates a new question that is bound to a template. By default each template has an associated
question with the same name. However, any number of questions can really be associated with a tem‐
plate, and this lets you create more such questions.

UNREGISTER question
This removes a question from the database.

PURGE Call this in your postrm when your package is purged. It removes all of your package's questions from
debconf's database.

Backend Database

$ man 7 debconf
Backend Database
Debconf uses a rather flexible and potentially complicated backend database for storing data such as the
answers to questions. The file /etc/debconf.conf is used to configure this database. If you need to
set up something complicated, like make debconf read a remote database to get defaults, with local
overrides, read the debconf.conf(5) man page for all the gory details. Generally, the backend database is
located in /var/cache/debconf/

Prioritats de debconf

$ man 7 debconf
Priorities
Another nice feature of debconf is that the questions it asks you are prioritized. If you don't want to be
bothered about every little thing, you can set up debconf to only ask you the most important questions. On
the other hand, if you are a control freak, you can make it show you all questions. Each question has a pri‐
ority. In increasing order of importance:
low Very trivial questions that have defaults that will work in the vast majority of cases.
medium Normal questions that have reasonable defaults.
high Questions that don't have a reasonable default.
critical
Questions that you really, really need to see (or else).
Only questions with a priority equal to or greater than the priority you choose will be shown to you. You
can set the priority value by reconfiguring debconf, or temporarily by passing --priority= followed
by the value to the dpkg-reconfigure(8) and dpkg-preconfigure(8) commands, or by setting the
DEBIAN_PRIORITY environment variable.

Plantilles. Templates

THE TEMPLATES FILE
A package that uses debconf probably wants to ask some ques‐
tions. These questions are stored, in template form, in the
templates file.
Like the config script, the templates file is put in the con‐
trol.tar.gz section of a deb. Its format is similar to a
debian control file; a set of stanzas separated by blank
lines, with each stanza having a RFC822-like form:
Template: foo/bar
Type: string
Default: foo
Description: This is a sample string question.
This is its extended description.
.
Notice that:
- Like in a debian package description, a dot
on its own line sets off a new paragraph.
- Most text is word-wrapped, but doubly-indented
text is left alone, so you can use it for lists
of items, like this list. Be careful, since
it is not word-wrapped, if it's too wide
it will look bad. Using it for short items
is best (so this is a bad example).
Template: foo/baz
Type: boolean
Description: Clear enough, no?
This is another question, of boolean type.
For some real-life examples of templates files, see
/var/lib/dpkg/info/debconf.templates, and other .templates
files in that directory.
Let's look at each of the fields in turn..
Template
The name of the template, in the 'Template' field, is
generally prefixed with the name of the package. After
that the namespace is wide open; you can use a simple
flat layout like the one above, or set up "subdirecto‐
ries" containing related questions.
Type The type of the template determines what kind of widget
is displayed to the user. The currently supported types
are:
string Results in a free-form input field that the user
can type any string into.
password
Prompts the user for a password. Use this with
caution; be aware that the password the user
enters will be written to debconf's database.
You should probably clean that value out of the
database as soon as is possible.
boolean
A true/false choice.
select A choice between one of a number of values. The
choices must be specified in a field named
'Choices'. Separate the possible values with
commas and spaces, like this:
Choices: yes, no, maybe
multiselect
Like the select data type, except the user can
choose any number of items from the choices list
(or choose none of them).
note Rather than being a question per se, this
datatype indicates a note that can be displayed
to the user. It should be used only for impor‐
tant notes that the user really should see,
since debconf will go to great pains to make
sure the user sees it; halting the install for
them to press a key. It's best to use these
only for warning about very serious problems,
and the error datatype is often more suitable.
error This datatype is used for error messages, such
as input validation errors. Debconf will show a
question of this type even if the priority is
too high or the user has already seen it.
title This datatype is used for titles, to be set with
the SETTITLE command.
text This datatype can be used for fragments of text,
such as labels, that can be used for cosmetic
reasons in the displays of some frontends. Other
frontends will not use it at all. There is no
point in using this datatype yet, since no fron‐
tends support it well. It may even be removed in
the future.

dpkg-reconfigure

dpkg-preconfigure

$ cat /etc/apt/apt.conf.d/70debconf
// Pre-configure all packages with debconf before they are installed.
// If you don't like it, comment it out.
DPkg::Pre-Install-Pkgs {"/usr/sbin/dpkg-preconfigure --apt || true";};

debconf-apt-progress

$ man debconf-apt-progress
...
Install the GNOME desktop and an X window system development
environment within a progress bar:
debconf-apt-progress -- aptitude -y install gnome x-window-system-dev
Install the GNOME, KDE, and XFCE desktops within a single progress bar,
allocating 45% of the progress bar for each of GNOME and KDE and the
remaining 10% for XFCE:

$ man debconf-set-selections
...
NAME
debconf-set-selections - insert new default values into the debconf database
SYNOPSIS
debconf-set-selections file
debconf-get-selections | ssh newhost debconf-set-selections
DESCRIPTION
debconf-set-selections can be used to pre-seed the debconf database with answers, or to change answers in the database. Each question will be marked as seen to
prevent debconf from asking the question interactively.
Reads from a file if a filename is given, otherwise from stdin.
WARNING
Only use this command to seed debconf values for packages that will be or are installed. Otherwise you can end up with values in the database for uninstalled
packages that will not go away, or with worse problems involving shared values. It is recommended that this only be used to seed the database if the originating
machine has an identical install.

DATA FORMAT
The data is a series of lines. Lines beginning with a # character are comments. Blank lines are ignored. All other lines set the value of one question, and
should contain four values, each separated by one character of whitespace. The first value is the name of the package that owns the question. The second is the
name of the question, the third value is the type of this question, and the fourth value (through the end of the line) is the value to use for the answer of the
question.
Alternatively, the third value can be "seen"; then the preseed line only controls whether the question is marked as seen in debconf's database. Note that
preseeding a question's value defaults to marking that question as seen, so to override the default value without marking a question seen, you need two lines.
Lines can be continued to the next line by ending them with a "\" character.

debconf-copydb

Permet fer una copia de seguretat:

debconf-copydb configdb backup

Copy all of configdb to backup, assuming you already have the backup database defined in
debconf.conf.

debconf-escape

TODO:

DEBCONF-ESCAPE(1) Debconf DEBCONF-ESCAPE(1)
NAME
debconf-escape - helper when working with debconf's escape capability
SYNOPSIS
debconf-escape -e < unescaped-text
debconf-escape -u < escaped-text
DESCRIPTION
When debconf has the 'escape' capability set, it will expect commands you send it to have backslashes and newlines escaped (as "\\"
and "\n" respectively) and will in turn escape backslashes and newlines in its replies. This can be used, for example, to
substitute multi-line strings into templates, or to get multi-line extended descriptions reliably using "METAGET".
SEE ALSO
debconf-devel(7) (available in the debconf-doc package)

Programar paquets utilitzant Debconf

$ man 7 debconf-devel
...
NAME
debconf - developers guide
DESCRIPTION
This is a guide for developing packages that use debconf.
This manual assumes that you are familiar with debconf as a user, and are familiar with the basics of
debian package construction.
This manual begins by explaining two new files that are added to debian packages that use debconf. Then it explains how the debconf protocol works, and points you at
some libraries that will let your programs speak the protocol. It discusses other maintainer scripts that debconf is typically used in: the postinst and postrm
scripts. Then moves on to more advanced topics like shared debconf templates, debugging, and some common techniques and pitfalls of programming with debconf. It
closes with a discussion of debconf's current shortcomings.

debconf-loadtemplate

Loads one or more template files into the debconf database.
The first parameter specifies the owner of the templates
(typically, the owner is the name of a debian package). The
remaining parameters are template files to load.

WARNING

This program should never be used from a maintainer script
of a package that uses debconf! It may however, be useful in
debugging, or to seed the debconf database.

Preconfigurant paquets per tal de poder-los instal·lar de forma desatesa

Exemple. Preconfiguració de les fonts de Windows. ttf-mscorefonts

Exemple. Preconfiguració de libnss-ldap

TODO

Apt is a wonderful tool, but it does have its quirks. One of those is that it likes to ask you interactive questions during package installation. This makes total sense when a human is doing apt-get install foobar, but it causes all sorts of consternation when you want to automatically install packages. (You do this all the time with Puppet, which I’ll talk more about at the end of this post.)

The answer to this problem is to pre-seed debconf with the correct answers to it’s questions. To do this, first you need to install the package by hand:

You’ll need to provide answers to the questions it asks, which we’re going to re-use later as the basis for our seed file. Next, make sure you have debconf-utils installed, and grab the answers to your questions:

Eines de traducció de Debconf

TODO

Unattended Package Installation

Del manual (man 7 debconf)

TODO:

If you have many machines to manage you will sometimes find yourself in the position of needing to perform
an unattended installation or upgrade of packages on many systems, when the default answers to some configu‐
ration questions are not acceptable. There are many ways to approach this; all involve setting up a database
and making debconf use it to get the answers you want.

You should really read debconf.conf(5) before this section, as you need to understand how debconf's data‐
bases work.

The easiest way to set up the database is to install the packages on one machine and answer their questions
as usual. Or you might just use dpkg-preconfigure(8) to configure a set of packages without actually
installing them. Or you might even decide to write a plain text debconf database by hand or something.

Once you have the database, you need to figure out how to make the remote systems use it. This depends of
course on the configuration of those systems and what database types they are set up to use.

If you are using the LDAP debconf database, an entire network of debian machines can also have any or all
package installation questions answered automatically by a single LDAP server.

But perhaps you're using something a little bit easier to set up like, say, the default debconf database
configuration, or you just don't want your remote systems to use LDAP all the time. In this case the best
approach is to temporarily configure the remote systems to stack your database underneath their own existing
databases, so they pull default values out of it. Debconf offers two environment variables, DEBCONF_DB_FALL‐
BACK and DEBCONF_DB_OVERRIDE, to make it easy to do this on the fly. Here is a sample use:

This makes the debconf on the remote host read in the data that is piped across the ssh connection and
interpret it as a plain text format debconf database. It then uses that database as a fallback database -- a
read-only database that is queried for answers to questions if the system's main debconf database lacks
answers.

Here's another way to use the DEBCONF_DB_FALLBACK environment variable:

Here ssh is used to set up a tunneled LDAP connection and run debconf. Debconf is told to use the LDAP
server as the fallback database. Note the use of "{host:localhost}" to configure how debconf accesses the
LDAP database by providing the "host" field with a value of "localhost".

Here you copy the database over with scp, and then ssh over and make debconf use the file you copied over.
This illustrates a shorthand you can use in the DEBCONF_DB_FALLBACK parameters -- if a field name is left
off, it defaults to "filename".

There is only one problem with these uses of the DEBCONF_DB_FALLBACK parameter: While the fallback database
can provide answers to questions the other debconf databases have never seen, it is only queried as a fall‐
back; after the other databases. If you need to instead temporarily override an existing value on the remote
host, you should instead use the DEBCONF_DB_OVERRIDE variable. Like DEBCONF_DB_FALLBACK, it sets up a tempo‐
rary database, but this database is consulted before any others, and can be used to override existing val‐
ues.

Variables d'entorn

ENVIRONMENT

DEBIAN_FRONTEND
Used to temporarily change the frontend debconf uses. See above.

DEBIAN_PRIORITY
Used to temporarily change the minimum priority of question debconf will display. See above.

DEBCONF_DEBUG
Turns on debugging output on standard error. May be set to a facility name or a regular expression
which matches a facility name (such as '.*' to output all debug info). The facility names include:

user Debugging info of interest to a debconf user.

developer
Debugging info of interest to a package developer.

db Debugging info about the backend database.

DEBCONF_NOWARNINGS
Set to "yes" to disable some warnings that debconf may display. Does not suppress display of fatal
errors.

DEBCONF_TERSE
Set to "yes" to enable terse mode, in which debconf frontends cut down on the verbiage as much as
possible.

DEBCONF_DB_FALLBACK
Stack a database after the normally used databases, so that it is used as a fallback to get configu‐
ration information from. See "Unattended Package Installation" above. If the value of the variable is
the name of an existing database in debconf.conf, then that database will be used. Otherwise, the
environment variable can be used to configure a database on the fly, by telling the type of database,
and optionally passing field:value settings, inside curly braces after the type. Spaces are used to
separate fields, so you cannot specify a field value containing whitespace.

Thus, this uses the fallbackdb in debconf.conf:
DEBCONF_DB_FALLBACK=fallbackdb

While this sets up a new database of type File, and tells it a filename to use and turns off backups:
DEBCONF_DB_FALLBACK=File{Filename:/root/config.dat Backup:no}

And as a shorthand, this sets up a database of type File with a filename:
DEBCONF_DB_FALLBACK=File{/root/config.dat}

Note that if a fallback database is set up on the fly, it will be read-only by default.

DEBCONF_DB_OVERRIDE
Stack a database before the normally used databases, so that it can override values from them. The
value of the variable works the same as does the value of DEBCONF_DB_FALLBACK.

DEBCONF_DB_REPLACE
Use a given database instead of the normally used databases. This may be useful for testing with a
separate database without having to create a separate debconf.conf, or to avoid locking the normal
databases.

DEBCONF_SYSTEMRC
If this environment variable is set, debconf will ignore a user's ~/.debconfrc file, and use the sys‐
tem one instead. If it is set to the name of a regular file, debconf will use that file in prefer‐
ence to the system configuration files.

DEBCONF_FORCE_DIALOG
If this environment variable is set, debconf will use dialog in preference to whiptail for the dialog
frontend.

DEBCONF_FORCE_XDIALOG
If this environment variable is set, debconf will use Xdialog in preference to whiptail for the dia‐
log frontend.

DEBCONF_NONINTERACTIVE_SEEN
Set to "true" to cause the seen flag to be set for questions asked in the noninteractive frontend.

Update Configuration File

TODO

$ man ucf
NAME
ucf - Update Configuration File: preserve user changes in configura‐
tion files
SYNOPSIS
ucf [options] <New File> <Destination>
ucf [options] --purge <Destination>
DESCRIPTION
This utility provides a means of asking the user whether or not to
accept new versions of configuration files provided by the package
maintainer, with various heuristics designed to minimize interaction
time. It uses debconf to interact with the user, as per Debian policy.
In the SYNOPSIS above, New file is the configuration file as provided
by the package (either shipped with the package, or generated by the
maintainer scripts on the fly), and Destination is the location (usu‐
ally under /etc) where the real configuration file lives, and is poten‐
tially modified by the end user. As far as possible, ucf attempts to
preserve the ownership and permission of the New file as it is copied
to the new location.

apt i dpkg

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).

If the directory name does not conform to this scheme, you must rename it before using dh_make. Alternatively, you may be able to use the --packagename option to force the package name.

CDBS (Common Debian Build System)

TODO:

cdbs (CDBS) is the Common Debian Build System. It provides (quoting from the package description) a "sane set of default rules upon which packages can build; any or all rules may be overridden as needed."

dh_make. Especificar la llicència: fitxer de copyright

Es pot fer amb l'opció -c:

$ dh_make -p miproyecto_1.0 -c gpl3 --createorig

dh_gencontrol

dh_installcron

$ man dh_installcron
DH_INSTALLCRON(1) Debhelper DH_INSTALLCRON(1)
NAME
dh_installcron - install cron scripts into etc/cron.*
SYNOPSIS
dh_installcron [debhelper options] [--name=name]
DESCRIPTION
dh_installcron is a debhelper program that is responsible for installing cron scripts.
FILES
debian/package.cron.daily
debian/package.cron.weekly
debian/package.cron.monthly
debian/package.cron.hourly
debian/package.cron.d
Installed into the appropriate etc/cron.*/ directory in the package build directory.
OPTIONS
--name=name
Look for files named debian/package.name.cron.* and install them as etc/cron.*/name, instead of
using the usual files and installing them as the package name.
SEE ALSO
debhelper(7)
This program is a part of debhelper.
AUTHOR
Joey Hess <joeyh@debian.org>
7.4.15ubuntu1 2009-11-17 DH_INSTALLCRON(1)

$ man dh_installcron
DH_INSTALLCRON(1) Debhelper DH_INSTALLCRON(1)
NAME
dh_installcron - install cron scripts into etc/cron.*
SYNOPSIS
dh_installcron [debhelper options] [--name=name]
DESCRIPTION
dh_installcron is a debhelper program that is responsible for installing cron scripts into etc/cron.*/ in package build directories. The files
debian/package.cron.daily, debian/package.cron.weekly, debian/package.cron.monthly, debian/package.cron.hourly, and debian/package.cron.d are installed.
OPTIONS
--name=name
Look for files named debian/package.name.cron.* and install them as etc/cron.*/name, instead of using the usual files and installing them as the package name.

dh_installlogrotate

$ man dh_installlogrotate
NAME
dh_installlogrotate - install logrotate config files
SYNOPSIS
dh_installlogrotate [debhelper options] [--name=name]
DESCRIPTION
dh_installlogrotate is a debhelper program that is responsible for installing logrotate config files into etc/logrotate.d in package build directories. Files named
debian/package.logrotate are installed.
OPTIONS
--name=name
Look for files named debian/package.name.logrotate and install them as etc/logrotate.d/name, instead of using the usual files and installing them as the package
name.
SEE ALSO
debhelper(7)
This program is a part of debhelper.
AUTHOR
Joey Hess <joeyh@debian.org>

DESTDIR

Triggers, activadors, disparadors

Podeu trobar la info a:

$ mandeb-triggers
deb-triggers(5) dpkg
utilities deb-triggers(5)
NAME
deb-triggers - package triggers
SYNOPSIS
triggers
DESCRIPTION
A package declares its relationship to some trigger(s) by including a triggers file in its control archive (i.e. DEBIAN/triggers during package creation).
This file contains directives, one per line. Leading and trailing whitespace and everything after the first # on any line will be trimmed, and empty lines will be ignored.
The trigger control directives currently supported are:
interest trigger-name
Specifies that the package is interested in the named trigger. All triggers in which a package is interested must be listed using this directive in the triggers control file.
activate trigger-name
Arranges that changes to this package's state will activate the specified trigger. The trigger will be activated at the start of the following operations: unpack, configure, remove (including for the benefit of a conflicting package), purge and deconfigure.
If this package disappears during the unpacking of another package the trigger will be activated when the disappearance is noted towards the end of the unpack. Trigger processing, and transition from triggers-awaited to installed, does not cause activations. In
the case of unpack, triggers mentioned in both the old and new versions of the package will be activated.
Unknown directives are an error which will prevent installation of the package.
SEE ALSO
dpkg-trigger(1), dpkg(1), /usr/share/doc/dpkg-dev/triggers.txt.gz.

i

$ sudogunzip /usr/share/doc/dpkg-dev/triggers.txt.gz
$ cat/usr/share/doc/dpkg-dev/triggers.txt
TRIGGERS
========
Introduction
------------
A dpkg trigger is a facility that allows events caused by one package
but of interest to another package to be recorded and aggregated, and
processed later by the interested package. This feature simplifies
various registration and system-update tasks and reduces duplication
of processing.
(NB: Triggers are intended for events that occur during package
installation, not events that occur in general operation.)
Concepts
--------
Each trigger is named, and at any time zero or more packages may be
interested in it.
We currently envisage three kinds of triggers:
* Explicit triggers. These can be activated by any program
by running dpkg-trigger (at any time, but ideally from a maintainer
script).
* File triggers. These are activated automatically by dpkg
when a matching file is installed, upgraded or removed as part
of a package. They may also be explicitly activated by running
dpkg-trigger.
* Future kinds of special triggers, which are activated by magic code
in dpkg itself. Currently none are defined besides file triggers.
A trigger is always activated by a particular package.
Trigger names contain only printing 7-bit ascii characters (no
whitespace). Each trigger kind has a distinct subset of the trigger
name space so that the kind can be determined from the name. After we
run out of straightforward syntaxes, we will use <kind>:<details>.
When a trigger is activated, it becomes pending for every package
which is interested in the trigger at that time. Each package has a
list of zero or more pending triggers. Repeated activation of the
same trigger has no additional effect. Note that in general a trigger
will not be processed immediately when it is activated; processing is
deferred until it is convenient (as described below).
At a trigger activation, the interested packages(s) are added to the
triggering package's list of triggers-awaited packages; the triggering
package is said to await the trigger processing.
A package which has pending triggers, or which awaits triggers, is not
considered properly installed. There are two new dpkg status values,
`triggers-pending' and `triggers-awaited', which lie between
`config-failed' and `installed'.
Details - Overview table
------------------------
Status Pending Awaited Satisfies Remedy
triggers triggers Depends
unpacked never maybe No postinst configure
c.-failed never maybe No postinst configure (when requested)
t.-awaited yes always No postinst triggered + fix awaited pkg(s)
t.-awaited no always No fix awaited package(s)
t.-pending always never Yes postinst triggered
installed never never Yes n/a
Packages in t-awaited and t-pending demand satisfaction of their
dependencies just like packages in installed.
Details - triggering package
----------------------------
When a package T activates a trigger in which a package I is
interested, I is added to the list of packages whose trigger
processing is awaited by T. Zero or more packages I may be added as a
result of any particular trigger activation, depending on how many
packages were interested. (If T chooses, explicit trigger activation
using dpkg-trigger of I by T need not make T become triggers-awaited
in this way..)
A package which awaits trigger processing but would otherwise be
`installed' or `triggers-pending' is considered to be in state
`triggers-awaited'. Packages in `triggers-awaited' do not satisfy
Depends dependencies.
Every triggered package I in T's list of awaited packages either has a
nonempty list of pending triggers, or is in `config-failed' or worse.
When I enters `installed' (or `config-files' or `not-installed'), the
entry in T's list of awaited packages is removed so that T may, if it
no longer awaits any packages, become `installed' or
`triggers-pending'.
Packages in `config-files' or `not-installed' do not await triggers.
Details - triggered package
---------------------------
When one of the triggers in which a package is interested is
activated, the triggered package has the trigger added to its list of
pending triggers. Packages with a nonempty list of pending triggers
which would otherwise be in state `installed' are in state
`triggers-pending' instead, so if the package was previously
`installed' it becomes `triggers-pending'.
If a package has nonempty lists both of pending and awaited triggers,
then it is in `triggers-awaited'. Nevertheless efforts will still be
made to process its triggers so as to make the list of pending
triggers empty.
To restore a package in state `triggers-pending' to `installed', or to
process pending triggers of a package with both pending and awaited
triggers, dpkg will run the postinst script:
postinst triggered "<trigger-name> <trigger-name> ..."
This will be attempted for each relevant package at the end of each
dpkg run; so, normally, in the same dpkg run as the event which made
the package go to `triggers-pending'. This leaves packages in
reasonable states by default.
If the `postinst triggered' run fails the package goes to
`config-failed', so that the trigger processing will not be attempted
again until explictly requested.
|
V
,------------.
| unpacked |
`------------'
|
|
(automatic)| ,----------.
| | config- |
| | failed |
| `----------'
| | ^
| | |
|,---<--' | ,------------------------------.
| (user | | triggers-pending |
postinst | request) | | or |
"configure" | | | t.-awaited with some pending |
| | `------------------------------'
| | | ^
|`----->------'| | |
| error | postinst | |
| | "triggered" | | trigger(s)
| | (automatic) | | activated
| | | |
| `-----<-----------'| |
| error | |
| | |
V V |
,--------------------------------------------------.
| installed or t.-awaited with none pending |
`--------------------------------------------------'
Packages in `config-failed' or worse are never considered to have
lists of pending triggers. A package whose postinst is being run
can however acquire pending triggers during that run (ie, a package
can trigger itself).
This means that if a triggering package T awaits trigger processing by
an interested package I, and I goes to `config-failed' or worse (eg,
during unpack for upgrade), then when I is reconfigured (goes to
`installed') or removed, T will no longer await processing by I, so
that T may automatically go from `triggers-awaited' to `installed'.
Or to put it another way, triggered actions are considered irrelevant
if the interested package I is not configured. When I's postinst is
called with `configure', it must do whatever actions are necessary to
deal with any trigger activations which might have occured while it
was not configured, just as if the package was being configured for
the first time.
Trigger processing should be idempotent. The list of triggers being
processed is provided to the postinst only so that it can optimise
away redundant processing.
In that case, where an interested package has more than one trigger
and wants to process them differently, the list of triggers can be can
be examined in a shell script like this:
case " $3 " in
*" trigger-name-a "*) process-trigger-a ;;
esac
Generally each trigger name should be tested for separately, as the
postinst will often be called for several triggers at once.
Note that if a package both activates triggers in other packages, and
is interested in triggers of its own, its postinst may run for trigger
processing before the postinst(s) of the package(s) it has triggered.
Timing guarantees, races, etc.
------------------------------
Activating a trigger will not have any immediate effect, although
putative resulting status changes will show up in dpkg --status etc.
(Putative because the actual status changes may depend on the state of
trigger interests when dpkg processes the trigger activation into
the status database, rather than that when dpkg --status is run.)
A package is only guaranteed to become notified of a trigger
activation if it is continuously interested in the trigger, and never
in `config-failed' or worse, during the period from when the trigger
is activated until dpkg runs the package postinst (either due to
--configure --pending, or at the end of the relevant run, as described
above). Subsequent to activation and before notification, the
interested package will not be considered in state `installed', so
long as the package remains interested, and the triggering package
will not be considered `installed'.
If the package is not in state `installed', `triggers-pending' or
`triggers-awaited' then pending triggers are not accumulated.
However, if such a package (between `half-installed' and
`config-failed' inclusive) declares some trigger interests then the
triggering packages *will* await their configuration (which implies
completion of any necessary trigger processing) or removal.
It is not defined in what order triggers will run. dpkg will make
some effort to minimise redundant work in the case where many packages
have postinst trigger processing activating another package's triggers
(for example, by processing triggers in fifo order during a single
dpkg run). Cycles in the triggering graph are prohibited and will
eventually, perhaps after some looping, be detected by dpkg and cause
trigger processing to fail; when this happens one of the packages
involved will be put in state `config-failed' so that the trigger loop
will not be reattempted. See `Cycle detection' below.
Explicit triggers
-----------------
Explicit triggers have names with the same syntax as package names,
*but* should *not* normally be named identically to a package.
When choosing an explicit trigger name it is usually good to include a
relevant package name or some other useful identifier to help make the
trigger name unique. On the other hand, explicit triggers should
generally not be renamed just because the interested or triggering
packages' names change.
Explicit trigger names form part of the interface between packages.
Therefore in case of wider use of any trigger the name and purpose
should be discussed in the usual way and documented in the appropriate
packaging guidelines (eg, in policy).
File triggers
-------------
File triggers have names of the form
/path/to/directory/or/file
and are activated when the specified filesystem object, or any object
under the specified subdirectory, is created, updated or deleted by
dpkg during package unpack or removal. The pathname must be absolute.
File triggers should not generally be used without mutual consent.
The use of a file trigger, and the name of the trigger used, should be
stated in policy, so that a package which creates a relevant file in a
maintainer script can activate the trigger explictly.
File triggers must definitely not be used as an escalation tool in
disagreements between different packages as to the desired contents of
the filesystem. Trigger activation due to a particular file should
not generally modify that file again.
Configuration files (whether dpkg-handled conffiles or not), or any
other files which are modified at times other than package management,
should not rely on file triggers detecting all modifications; dpkg
triggers are not a general mechanism for filesystem monitoring.
If there are or might be directory symlinks which result in packages
referring to files by different names, then to be sure of activation
all of the paths which might be included in packages should be listed.
The path specified by the interested package is matched against the
path included in the triggering package, not against the truename of
the file as installed. Only textually identical filenames (or
filenames where the interest is a directory prefix of the installed
file) are guaranteed to match.
A file trigger is guaranteed to be activated before the file in
question is modified by dpkg; on the other hand, a file trigger might
be activated even though no file was actually modified. Changes made
by dpkg to the link count of a file, or to solely the inode number
(ie, if dpkg atomically replaces it with another identical file), are
not guaranteed to cause trigger activation.
Because of the restriction on trigger names, it is not possible to
declare a file trigger for a directory whose name contains whitespace,
i18n characters, etc. Such a trigger should not be necessary.
Package declarations regarding triggers
---------------------------------------
See deb-triggers(5).
Support future extension of the trigger name syntax with additional
dpkg-generated triggers is as follows: a package which is interested
in any unsupported trigger kinds cannot be configured (since such a
package cannot be guaranteed to have these triggers properly activated
by dpkg). Therefore no package can be interested in any unsupported
trigger kinds and they can be freely activated (both by `activate' and
by dpkg-trigger). dpkg-deb will be changed to warn about unrecognised
trigger names syntaxes and unrecognised trigger control directives.
New command-line interfaces to dpkg tools
-----------------------------------------
See dpkg(1).
Here is a summary of the behaviours:
Command line Trigproc Trigproc Configure
these any triggered
----------------------+---------------+---------------+-----------------
--unpack no usually[1] none
--remove n/a usually[1] none
--install n/a usually[1] these
--configure -a any needed usually[1] any needed
--configure <some> if needed usually[1] must, or trigproc
--triggers-only -a any needed usually[1] none
--triggers-only <some> must usually not[1] none
[1] can be specified explicitly by --triggers or --no-triggers
See dpkg-trigger(1).
A trigger may be activated explicitly with:
dpkg-trigger [--by-package <package>] <name-of-trigger>
dpkg-trigger --no-await <name-of-trigger>
The --verbose and --query options will show which packages were
interested and what the current activation state is, on stdout in
human- and machine-readable (untranslated) format. Without any
options there will be no output to stdout, and none to stderr unless
dpkg-trigger is unable to make a record of the trigger activation.
With --query no trigger is activated.
NB that in the case of a file trigger the name of the trigger is
needed, not the name of a file which would match the trigger.
apt and aptitude
----------------
These must be taught about the new `triggers-awaited' and
`triggers-pending' states. Packages in these states should be treated
roughly like those in `unpacked': the remedy is to run dpkg
--configure.
Normally apt and aptitude will not see packages in `triggers-pending'
since dpkg will generally attempt to run the triggers thus leaving the
package in `config-failed' or `installed'.
Note that automatic package management tools which call dpkg (like apt
and aptitude) should not attempt to configure individual packages in
state `triggers-pending' (or indeed `triggers-awaited') with dpkg
--triggers-only <package>... or dpkg --no-triggers --configure <package>...,
or similar approaches. This might defeat dpkg's trigger cycle detection.
A package management tool which will run dpkg --configure --pending at
the end may use --no-triggers on its other dpkg runs. This would be
more efficient as it allows more aggressive deferral (and hence more
unification) of trigger processing.
Error handling
--------------
Packages should be written so that they DO NOT BREAK just because
their pending triggers have not yet been run. It is allowed for the
functionality relating to the unprocessed trigger to fail (ie, the
package which is awaiting the trigger processing may be broken), but
the remainder of the interested package must work normally.
For example, a package which uses file triggers to register addons
must cope with (a) an addon being dropped into the filesystem but not
yet registered and (b) an addon being removed but not yet
deregistered. In both of these cases the package's main functionality
must continue to work normally; failure of the addon in question is
expected, warning messages are tolerable, but complete failure of the
whole package, or failures of other addons, are not acceptable.
dpkg cannot ensure that triggers are run in a timely enough manner for
pathological error behaviours to be tolerable.
Where a trigger script finds bad data provided by a triggering
package, it should generally report to stderr the problem with the bad
data and exit nonzero, leaving the interested package in config-failed
and the triggering package in triggers-awaited and thus signalling the
problem to the user.
Alternatively, in some situations it may be more desirable to allow
the interested package to be configured even though it can only
provide partial service. In this case clear information will have to
be given in appropriate places about the missing functionality, and a
record should be made of the cause of the errors. This option is
recommended for situations where the coupling between the interested
and triggering package is particularly loose; an example of such a
loose coupling would be Python modules.
WORKED EXAMPLE - SCROLLKEEPER
=============================
Currently, every Gnome program which comes with some help installs the
help files in /usr/share/gnome/help and then in the postinst runs
scrollkeeper-update. scrollkeeper-update reads, parses and rewrites
some large xml files in /var/lib/scrollkeeper; currently this
occurs at every relevant package installation, upgrade or removal.
When triggers are available, this will work as follows:
* gnome-foobar will ship its `omf' file in /usr/share/omf as
normal, but will not contain any special machinery to invoke
scrollkeeper.
* scrollkeeper will in its triggers control file say:
interest /usr/share/omf
and in its postinst say:
scrollkeeper-update-now -q
dpkg will arrange that this is run once at the end of each run
where any documentation was updated.
Note that it is not necessary to execute this only on particular
postinst "$1" values; however, at the time of writing, scrollkeeper
does this:
if [ "$1" = "configure" ]; then
printf "Rebuilding the database. This may take some time.\n"
scrollkeeper-rebuilddb -q
fi
and to retain this behaviour, something along the following lines
would be sensible:
if [ "$1" = "configure" ]; then
printf "Rebuilding the database. This may take some time.\n"
scrollkeeper-rebuilddb -q
else
printf "Updating GNOME help database.\n"
scrollkeeper-update-now -q
fi
* dh_scrollkeeper will only adjust the DTD declarations and no longer
edit maintainer scripts.
Full implementation of the transition plan defined below, for
scrollkeeper, goes like this:
1. Update scrollkeeper:
- Add a `triggers' control archive file containing
interest /usr/share/omf
- Make the postinst modifications as described above.
- Rename scrollkeeper-update to scrollkeeper-update-now
- Provide a new wrapper script as scrollkeeper-update:
#!/bin/sh -e
if type dpkg-trigger >/dev/null 2>&1 && \
dpkg-trigger /usr/share/omf; then
exit 0
fi
exec scrollkeeper-update-now "$@"
2. In gnome-policy chapter 2, `Use of scrollkeeper',
- delete the requirement that the package must depend on
scrollkeeper
- delete the requirement that the package must invoke
scrollkeeper in the postinst and postrm
- instead say:
OMF files should be installed under /usr/share/omf in the
usual way. A dpkg trigger is used to arrange to update the
scrollkeeper documentation index automatically and no special
care need be taken in packages which supply OMFs.
If an OMF file is placed, modified or removed other than as
an file installed in the ordinary way by dpkg, the dpkg file
trigger `/usr/share/omf' should be activated; see the dpkg
triggers specification for details.
Existing packages which Depend on scrollkeeper (>= 3.8)
because of dh_scrollkeeper or explicit calls to
scrollkeeper-update should be modified not to Depend on
scrollkeeper.
3. Update debhelper's dh_scrollkeeper not to edit maintainer
scripts. One of dh_scrollkeeper or lintian should be changed to
issue a warning for packages with scrollkeeper (>= 3.8) in the
Depends control file line.
4. Remove the spurious dependencies on scrollkeeper, at our leisure.
As a bonus, after this is complete it will be possible to remove
scrollkeeper while keeping all of the documentation-supplying
gnome packages installed.
5. If there are any packages which do by hand what dh_scrollkeeper
does, change them not to call scrollkeeper-update and drop
their dependency on scrollkeeper.
This is not 100% in keeping with the full transition plan defined
below: if a new gnome package is used with an old scrollkeeper, there
is some possibility that the help will not properly be available.
Unfortunately, dh_scrollkeeper doesn't generate the scrollkeeper
dependency in the control file, which makes it excessively hard to get
the dependency up to date. The bad consequences of the inaccurate
dependencies are less severe than the contortions which would be
required to deal with the problem.
TRANSITION PLAN
===============
Old dpkg to new dpkg
--------------------
The first time a trigger-supporting dpkg is run on any system, it will
activate all triggers in which anyone is interested, immediately.
These trigger activations will not be processed in the same dpkg run,
to avoid unexpectedly processing triggers while attempting an
unrelated operation. dpkg --configure --pending (and not other dpkg
operations) will run the triggers, and the dpkg postinst will warn the
user about the need to run it (if this deferred triggers condition
exists). (Any triggers activated or reactivated *after* this
mass-activation will be processed in the normal way.)
To use this correctly:
* Packages which are interested in triggers, or which want to
explicitly activate triggers, should Depend on the
triggers-supporting version of dpkg.
* Update instructions and tools should arrange to run
dpkg --configure --pending
after the install; this will process the pending triggers.
dpkg's prerm will check for attempts to downgrade while triggers are
pending and refuse. (Since the new dpkg would be installed but then
refuse to read the status file.) In case this is necessary a separate
tool will be provided which will:
* Put all packages with any pending triggers into state
`config-failed' and remove the list of pending triggers.
* Remove the list of awaited triggers from every package. This
may cause packages to go from `triggers-awaited' to `installed'
which is not 100% accurate but the best that can be done.
* Remove /var/lib/dpkg/triggers (to put the situation to that which
we would have seen if the trigger-supporting dpkg had never been
installed).
Higher-level programs
---------------------
The new dpkg will declare versioned Conflicts against apt and aptitude
and other critical package management tools which will be broken by
the new Status field values. Therefore, the new higher-level tools
will have to be deployed first.
The new dpkg will declare versioned Breaks against any known
noncritical package management tools which will be broken by the new
Status field value.
Transition hints for existing packages
--------------------------------------
When a central (consumer) package defines a directory where other leaf
(producer) packages may place files and/or directories, and currently
the producer packages are required to run an `update-consumer' script
in their postinst:
1. In the relevant policy, define a trigger name which is the name of
the directory where the individual files are placed by producer
packages.
2. Update the consumer package:
* Declare an interest in the trigger.
* Edit update-consumer so that if it is called without --real
it does the following:
if type dpkg-trigger >/dev/null 2>&1 && \
dpkg-trigger name-of-trigger; then
exit 0
fi
If this fails to cause update-consumer to exit, it should do
its normal update processing. Alternatively, if it is more
convenient, update-consumer could be renamed and supplanted with
a wrapper script which conditionally runs the real
update-consumer.
* In the postinst, arrange for the new `triggered' invocation to
run update-consumer --real. The consumer package's postinst
will already run update-consumer during configuration, and this
should be retained and supplemented with the --real option (or
changed to call the real script rather than the wrapper).
3. Update the producer packages:
* In the postinst, remove the call to update-consumer
* Change the dependency on consumer to be versioned, specifying a
trigger-interested consumer.
This can be done at our leisure. Ideally for loosely coupled
packages this would be done only in the release after the one
containing the triggers-interested consumer, to facilitate partial
upgrades and backports.
4. After all producer packages have been updated according to step 3,
`update-consumer' has become an interface internal to the consumer
and need no longer be kept stable. If un-updated producers are
still of interest, incompatible changes to `update-consumer' imply
a versioned Breaks against the old producers.
(See also `Transition plan', below.)
If there are several consumer packages all of which are interested in
the features provided by producer packages, the current arrangements
usually involve an additional central switchboard package (eg,
emacsen-common). In this case:
-- NOTE - this part of the transition plan is still a proof of
concept and we might yet improve on it
1. Define the trigger name.
2. Update the switchboard to have any new functionality needed by the
consumers in step 3 (2nd bullet).
3. Update the consumer packages:
* Declare an interest in the trigger.
* In the postinst, arrange for the new `trigger' invocation to run
the compilation/registration process. This may involve scanning
for new or removed producers, and may involve new common
functionality from the switchboard (in which case a versioned
Depends is needed).
* The old interface allowing the switchboard to run
compilation/registration should be preserved, including
calls to the switchboard to register this consumer.
4. When all consumers have been updated, update the switchboard:
* Make the registration scripts called by producers try to
activate the trigger and if that succeeds quit without
doing any work (as for bullet 2 in the simple case above).
* Versioned Breaks, against the old (pre-step-3) consumers.
5. After the switchboard has been updated, producers can be updated:
* Remove the calls to the switchboard registration/compilation
functions.
* Change the dependency on the switchboard to a versioned one,
specifying the one which Breaks old consumers. Alternatively,
it may be the case that the switchboard is no longer needed (or
not needed for this producer), in which case the dependency on
the switchboard can be removed in favour of an appropriate
versioned Breaks (probably, identical to that in the new
switchboard).
6. After all the producers have been updated, the cruft in the
consumers can go away:
* Remove the calls to the switchboard's registration system.
* Versioned Breaks against old switchboards, or versioned Depends
on new switchboards, depending on whether the switchboard is
still needed for other common functionality.
7. After all of the producers and consumers have been updated, the
cruft in the switchboard can go away:
* Remove the switchboard's registration system (but not obviously
the common functionality from step 3, discussed above).
* Versioned Breaks against pre-step-6 consumers and pre-step-5
producers.
DISCUSSION
==========
The activation of a trigger does not record details of the activating
event. For example, file triggers do not inform the package of the
filename. In the future this might be added as an additional feature,
but there are some problems with this.
Broken producer packages, and error reporting
---------------------------------------------
Often trigger processing will involve a central package registering,
compiling or generally parsing some data provided by a leaf package.
If the central package finds problems with the leaf package data it is
usually more correct for only the individual leaf package to be
recorded as not properly installed. There is not currently any way to
do this and there are no plans to provide one.
The naive approach of giving the postinst a list of the triggering
packages does not work because this information is not recorded in the
right way (it might suffer from lacunae); enhancing the bookkeeping
for this to work would be possible but it is far better simply to make
the system more idempotent. See above for the recommended approach.
INTERNALS
=========
On-disk state
-------------
A single file /var/lib/dpkg/triggers/File lists all of the filename
trigger interests in the form
/path/to/directory/or/file package
For each explicit trigger in which any package is interested,
a file /var/lib/dpkg/triggers/<name-of-trigger> is a list of
the interested packages, one per line.
These interest files are not updated to remove a package just because
a state change causes it not to be interested in any triggers any more
- they are updated when we remove or unpack.
For each package which has pending triggers, the status file contains
a Triggers-Pending field which contains the space-separated names of
the pending triggers. For each package which awaits triggers the
status file contains a Triggers-Awaited field which contains the
*package* names of the packages whose trigger processing is awaited.
See `Details - Overview table' above for the invariants which relate
Triggers-Pending, Triggers-Awaited, and Status.
During dpkg's execution, /var/lib/dpkg/triggers/Unincorp is a list of
the triggers which have been requested by dpkg-trigger but not yet
incorporated in the status file. Each line is a trigger name followed
by one or more triggering package names. The triggering package name
"-" is used to indicate one or more package(s) which did not need to
await the trigger.
/var/lib/dpkg/triggers/Lock is the fcntl lockfile for the trigger
system. Processes hang onto this lock only briefly: dpkg-trigger
to add new activations, or dpkg to incorporate activations (and
perhaps when it updates interests). Therefore this lock is always
acquired with F_GETLKW so as to serialise rather than fail on
contention.
Processing
----------
dpkg-trigger updates triggers/Unincorp, and does not read or write the
status file or take out the dpkg status lock. dpkg (and dpkg-query)
reads triggers/Unincorp after reading /var/lib/dpkg/status, and after
running a maintainer script. If the status database is opened for
writing then the data from Unincorp is moved to updates as
Triggers-Pending and Triggers-Awaited entries and corresponding Status
changes.
This means that dpkg is guaranteed to reincorporate pending trigger
information into the status file only 1. when a maintainer script has
finished, or 2. when dpkg starts up with a view to performing some
operation.
When a package is unpacked or removed, its triggers control file will
be parsed and /var/lib/dpkg/triggers/* updated accordingly.
Triggers are run as part of configuration. dpkg will try to first
configure all packages which do not depend on packages which are
awaiting triggers, and then run triggers one package at a time in the
hope of making useful progress. (This will involve a new `dependtry'
level in configure.c's algorithm.) The only constraint on the
ordering of postinsts is only the normal Depends constraint, so the
usual Depends cycle breaking will function properly. See `Cycle
detection' below regarding cycles in the `A triggers B' relation.
Processing - Transitional
-------------------------
The case where a triggers-supporting dpkg is run for the first time is
detected by the absence of /var/lib/dpkg/triggers/Unincorp. When the
triggers-supporting dpkg starts up without this it will set each
package's list of pending triggers equal to its interests (obviously
only for packages which are in `installed' or `triggers-pending').
This may result in a package going from `installed' to
`triggers-pending' but it will not create the directory at this time.
Packages marked as triggers-pending in this way will not be scheduled
for trigger processing in this dpkg run.
dpkg will also at this time create /var/lib/dpkg/triggers if
necessary, triggers/File, triggers/Unincorp, and the per-trigger
package lists in /var/lib/dpkg/triggers/<trigger-name>, so that future
trigger activations will be processed properly.
Only dpkg may create /var/lib/dpkg/triggers and only when it is
holding the overall dpkg status lock.
dpkg and/or dpkg-deb will be made to reject packages containing
Triggers-Pending and Triggers-Awaited control file fields, to prevent
accidents.
Cycle detection
---------------
In addition to dependency cycles, triggers raise the possibility of
mutually triggering packages - a cycle detectable only dynamically,
which we will call a `trigger cycle'.
Trigger cycles are detected using the usual hare-and-tortoise
approach. Each time after dpkg runs a postinst for triggers, dpkg
records the set of pending triggers (ie, the set of activated <pending
package, trigger name> tuples). If the hare set is a superset of the
tortoise set, a cycle has been found.
For guaranteed termination, it would be sufficient to declare a cycle
only when the two sets are identical, but because of the requirement
to make progress we can cut this short. Formally, there is supposed
to be a complete ordering of pending trigger sets satisfying the
condition that any set of pending triggers is (strictly) greater than
all its (strict) subsets. Trigger processing is supposed to
monotonically decrease the set in this ordering. (The set elements
are <package, trigger name> tuples.)
(See `Processing' above for discussion of dependency cycles.)
--

Could not find a signing program (pgp or gpg)!
debuild: fatal error at line 1269:
running debsign failed
Command '/bin/sh -c debuild ' failed in '/home/sergi/SVN/openfpnet-common/build-area/openfpnet-common-0.1', how to continue now? [Qri?]:

Abusing dh_installdirs .dirs Files

TODO

Many packages wrongly use dh_installdirs and .dirs files to create directories. 99% of those cases are not necessary, since dh_install and .install files will automatically take care of creating directories. You only need to use dh_installdirs if your package needs to ship empty nonstandard directories, e. g. /etc/mypackage/plugins.d/.

This package was debianized by Sergi Tur Badenas <sergi.tur@upc.edu> on
Tue, 5 Jun 2007 13:01:02 +0200.
It was downloaded from <fill in http/ftp site>
Upstream Author: <put author(s) name and email here>
Copyright: <put the year(s) of the copyright, and the names of the
copyright holder(s) here>
License:
<Put the license of the package here>
The Debian packaging is (C) 2007, Sergi Tur Badenas <sergi.tur@upc.edu> and
is licensed under the GPL, see `/usr/share/common-licenses/GPL'.
# Please also look if there are files or directories which have a
# different copyright/license attached and list them here.

This file specifies the directories which we need but the normal installation procedure ("make install DESTDIR=..." invoked by "dh_auto_install") somehow doesn't create. This generally means there is a problem with the Makefile.

$ man echod
ECHOD(SECTION) ECHOD(SECTION)
NAME
echod - program to do something
SYNOPSIS
echod [options] files...
bar [options] files...
DESCRIPTION
This manual page documents briefly the echod and bar commands.
echod is a program that...
OPTIONS
These programs follow the usual GNU command line syntax, with long options starting with two dashes (‘-’). A summary of options is included
below. For a complete description, see the Info files.
-h, --help
Show summary of options.
-v, --version
Show version of program.
SEE ALSO
bar(1), baz(1).
The programs are documented fully by The Rise and Fall of a Fooish Bar, available via the Info system.
AUTHOR
echod was written by <upstream author>.
This manual page was written by Sergi Tur Badenas <sergi.tur@upc.edu>, for the Debian project (but may be used by others).