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) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
