Debian-news is about one simple thing - news about Debian GNU/Linux and the top free distributions based on Debian GNU/Linux.


Bits from dpkg developers – dpkg 1.16.1

we just released dpkg 1.16.1 to unstable. It comes with several disruptive changes that you need to be aware of. Please read carefully.

This mail also includes a list of features and important changes since our
last announcement for dpkg 1.15.7.

Disruptive changes

* dpkg-buildpackage no longer exports CFLAGS/CXXFLAGS/LDFLAGS/CPPFLAGS/FFLAGS

It was not the proper approach to inject build flags since those
variables would not be set when calling debian/rules directly. So
we introduced dpkg-buildflags to solve the problem, and each
package is then responsible of retrieving the flags and injecting
them in the build process.

Any CDBS package should already use dpkg-buildflags transparently.
Packages using dh with debian/compat=9 are also covered (dh sets
the environment variables like dpkg-buildpackage used to do). All
the other packages need to be adjusted. But it’s now easier than
before with dpkg-dev 1.16.1.

With an autoconf-based package, you can adjust your ./configure
invocation in debian/rules like this:

./configure $(shell dpkg-buildflags –export=configure)

If you want to export the compilation flags in the environment like
dpkg-buildpackage used to do, you can simply put this at the top of
your debian/rules:

include /usr/share/dpkg/

Or for more fine grained control explicitly export the variables

include /usr/share/dpkg/

You can also use “-include” to not fail when the file is missing and
make the package more backport-friendly. Otherwise, in both cases
you will have to build-depend on dpkg-dev (>= 1.16.1). We’ll try to
provide a backport at least for squeeze to make it easier to
backport packages using those features.

* dpkg-buildflags now returns hardening build flags by default

While the Ubuntu archive already enables hardening by default, this
change might break some packages in Debian (either at build or at
run-time). If that is the case, you must be aware that you can
disable the problematic hardening feature by setting
DEB_BUILD_MAINT_OPTIONS in debian/rules. See dpkg-buildflags(1) for
details. Of course, you can only be affected if you’re actually
using dpkg-buildflags as expected (see previous point).

Two hardening features are not enabled by default: PIE and bindnow.
If your package supports PIE, you might want to consider enabling it.
If the binaries are long running processes like daemons, and as such
the startup performance penalty of “bindnow” is acceptable, it might
be a good idea to enable it too but only if relro is in effect,
although another option might be to just define LD_BIND_NOW=1 on the
daemon’s environment (for example in the init.d script), in which case
the sysadmin can always disable it, something that’s not possible with
the build option.

Note that “$(shell dpkg-buildflags –export=configure)” does not
inherit environment variables set via “export” in the rules files,
so if you use that construct and want to enable PIE and bindnow
(or disable something else), you must embed the variable
initialization like this:

dpkg_buildflags = DEB_BUILD_MAINT_OPTIONS=”hardening=+pie,+bindnow” dpkg-buildflags
./configure $(shell $(dpkg_buildflags) –export=configure)

* “dpkg-source -b” on a “2.0” or “3.0 (quilt)” source package will fail
if it detects upstream changes which are not managed by a quilt patch.

You are expected to call “dpkg-source –commit” if you want to
record those changes permanently. In this process, you will have
to give a patch name and you will be invited to edit the DEP-3
headers[1] of the new patch.

New features

* dpkg-dev now provides some (self-documented) Makefile snippets that
you can include in debian/rules in order to set some variables that
are frequently useful in a such a file:
* /usr/share/dpkg/
This file includes all the files listed below.
* /usr/share/dpkg/
This sets all the variables that you can retrieve with
* /usr/share/dpkg/
returned by dpkg-buildflags. The variables are exported in the
environment only if DPKG_EXPORT_BUILDFLAGS is set.
* /usr/share/dpkg/
This provides information extracted from the changelog and the
control file like source package name and various version
related variables.
* /usr/share/dpkg/
This provides some vendor related information and a macro that
can be used to verify whether the current vendor derives from
a given distribution.

* When dpkg-source automatically applies patches at the start of the
build process, it will also automatically unapply them at the end
of a successful build. This should provide a better experience to
people building from a VCS repository with patches kept unapplied.
(There’s also the new –unapply-patches option, although not usually
needed given the current default.)

* dpkg-buildflags supports new environment variables
(DEB__MAINT_) that are meant to be used by the
package maintainer to adjust the set of build flags returned. Two
new operations are now available (PREPEND and STRIP), they
complement SET and APPEND which were already supported.

This ensures that the maintainer can adjust the build flags even
if the dpkg-buildflags call is hidden behind a helper script.

* dpkg-buildflags got two new actions –export and –dump, the latter
being now the default.

* dpkg-buildpackage now allows to explicitly specify a full build with
the new -F option when combined with -nc.

* dpkg-deb gains –raw-extract which combines –extract and –control.
The resulting directory has the required structure to be fed to a
new invocation of “dpkg-deb –build”. Very useful for quick
hand-made changes to a package.

* dpkg-deb got a new –verbose option, that can also be used with
–extract to get an equivalent result to –vextract.

* dpkg-split now adds the architecture to the split .deb debian-split
control member so that it can track it to generate correct package
file names on –join.

* dpkg-divert now uses the dpkg set environment variable
DPKG_MAINTSCRIPT_PACKAGE if neither of –package or –local were
specified. This should not be used yet on packages for Debian, because
squeeze’s dpkg-divert does not understand it, and as such would end up
assuming a local diversion.

* There are some new trigger directives (“interest-noawait” and
“activate-noawait”) that work like the existing directives except
that packages activating the triggers are not put in the
“triggers-awaited” status, they go straight to “installed” or
“triggers-pending”. The difference is significant because packages
in “triggers-awaited” do not satisfy dependencies and can thus
force an early trigger processing that we’d like to avoid.

If the trigger processing is not critical for the activating package
to actually work, then you should consider using these new
directives. If you do so, you will have to add a
“Pre-Depends: dpkg (>= 1.16.1)” to ensure the new dpkg is
installed even before your package is unpacked. If you’re not
sure whether it’s safe to add this Pre-Depends on your package,
please consult for advice. See
deb-triggers(5) for details on this new feature.

* dpkg got a new –status-logger option similar to –status-fd but
instead invokes the command itself.

* dpkg allows to filter paths at installation time with the new
–path-exclude and –path-include options.

* dpkg can now be forced to show the conffile prompt even if there was
no changes in the file on the package with the new –force-confask.

* dpkg allows to install again packages with bogus versions with the
new –force-bad-version option.

* dpkg allows to perform unsafe I/O operations when unpacking the file
system .deb member with the new –force-unsafe-io (NOT RECOMMENDED!).

* start-stop-daemon gains –status to help implement LSB Init Script
status actions.

Misc changes

* The Installed-Size field is now computed with “du –apparent-size”
so that the current filesystem block size should no longer affect
the resulting value. It will usually be smaller compared to the
previously generated value.


This version does not yet have multiarch support (but it does know
the Multi-Arch field, so it will no longer output the unknown field
warning). The next version (1.16.2) should be the one introducing
multiarch support and will probably be uploaded to experimental
first in the hopefully not-too-distant future.

Thank you for your attention.

Guillem and Raphaël,
the dpkg maintainers.

[1] DEP-3:

Raphaël Hertzog ◈ Debian Developer

No Response to “Bits from dpkg developers – dpkg 1.16.1” »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Debian-News is not related to the Debian Project.
All logos and trademarks on this site are property of their respective owners.