Proposal for a "Bits from dpkg developers"
On Wed, 07 Sep 2011, Guillem Jover wrote:
> It's been some time now since last upload (a busy summer for me with
> guests over during most of it!), and quite some changes have
> accumulated, so let's set as tentative target this next sunday for
> 1.16.1.
Given the number of disruptive changes, it's important to accompany
the upload with a d-d-a mail. I have thus prepared a draft here:
http://titanpad.com/wHeHZd9yrs
Some important points to note:
- I mention a backport that I plan to prepare once this version
reaches testing. If anyone thinks it's a bad idea, shout up
now and tell me why.
- I speak quickly of multiarch at the end to announce that 1.16.2
will have it, that it will go to experimental first and that
it will happen relatively quickly. Guillem, tell me if this
is ok with you.
For your convenience, here's a copy of the current version. If you
see spelling mistakes, please correct them in the titanpad copy.
Thank you.
----
Subject: Bits from dpkg developers - dpkg 1.16.1
Hello,
we just released dpkg 1.16.1 to unstable. It comes with a large
number of changes that you need to be aware of. Please read carefully.
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. 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:
DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/buildflags.mk
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).
PIE is the only hardening feature that is not enabled by default but
if your package supports it, it's a good idea to enable it.
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 (or disable
something else), you must embed the variable initialization
like this:
dpkg_buildflags = DEB_BUILD_MAINT_OPTIONS="hardening=+pie" dpkg-buildflags
[...]
./configure $(shell $(dpkg_buildflags) --export=configure)
* “dpkg-source -b” on a “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
------------
* 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 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. See deb-triggers(5)
for details.
* 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/default.mk
This file includes all the files listed below.
* /usr/share/dpkg/architecture.mk
This sets all the variables that you can retrieve with
dpkg-architecture.
* /usr/share/dpkg/buildflags.mk
This sets CFLAGS/CXXFLAGS/LDFLAGS/CPPFLAGS/FFLAGS with the values
returned by dpkg-buildflags. The variables are exported in the
environment only if DPKG_EXPORT_BUILDFLAGS is set.
* /usr/share/dpkg/pkg-info.mk
This provides information extracted from the changelog and the
control file like source package name and various version
related variables.
* /usr/share/dpkg/vendor.mk
This provides some vendor related information and a macro that
can be used to verify whether the current vendor derives from
a given distribution.
* dpkg-buildflags supports new environment variables
(DEB_<flag>_MAINT_<operation>) 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 an helper script.
* 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.
* 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.
Multiarch
---------
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) will be the one introducing
multiarch support and shall be uploaded to experimental in the
hopefully not-too-distant future.
Thank you for your attention.
Guillem and Raphaël,
the dpkg maintainers.
[1] DEP-3: http://dep.debian.net/deps/dep3
-----
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: