As you'll know from my last mail in January, while sarge base was frozen dpkg development wasn't frozen along with it; the 1.13 branch was being maintained in experimental. Now that sarge (and sarge+0.01) is out of the door, this development branch is now moving to unstable with today's upload of 1.13.9 ("On like Donkey Kong"). The 1.13 branch is an unstable development branch; where there is a good reason to change something, it is changed at the expense of breaking other pieces of software. I'll be sure to keep you all apprised of such breakages through further mails to this list. 1.13 releases will be uploaded directly to unstable for the next few months, after which point we'll all take a breath to stabilise it again. There may then be another round of unstable releases and stabilisation before etch base freezes, depending on when that occurs. The rest of this mail is a summary of the changes between 1.10 and 1.13, some of which will affect existing packages and perhaps tools that use dpkg. dpkg-architecture changes ------------------------- One of the ongoing goals of the 1.13 branch is to improve the way dpkg handles architectures, in particular a cpu/os split so that the tools are aware that "i386" is a Linux OS with an i386 CPU, and that "hurd-i386" has the same CPU but the Hurd OS. These changes have been made in discussion with and with the help of ports maintainers such as Robert Millan and Jeff Bailey. So far the most affected tool is dpkg-architecture, which now has new variables which contain the architecture information: * DPKG_HOST_ARCH, DPKG_BUILD_ARCH As before, these contain the full Debian architecture string for the target and build-system architectures; e.g. "i386" (for Linux i386), "amd64" (for Linux amd64) and "hurd-amd64" (for Hurd amd64). * DPKG_HOST_ARCH_OS, DPKG_BUILD_ARCH_OS These new variables contain the Debian Operating System string for the target and build-system architectures; e.g. "linux", "linux" and "hurd" (for the same examples as above). * DPKG_HOST_ARCH_CPU, DPKG_BUILD_ARCH_CPU These new variables contain the Debian CPU string for the target and build-system architectures; e.g. "i386", "amd64" and "amd64". These variables are assigned by Debian and tend not to change, so they are perfect for debian/rules files that need to take different action depending on the target or build-system architecture. Other tools can use the new /usr/share/dpkg/ostable and /usr/share/dpkg/cputable files to map between Debian and GNU names for the architectures and match config.guess output against the regular expression for each one. The old /usr/share/dpkg/archtable file is deprecated and now only contains a list of the released architectures. In future releases dpkg-dev will be improved along similar lines, so you'll be able to declare a binary package for any Linux architecture without having to list every CPU type; and declare CPU or OS specific build-dependencies. And on the longer term, dpkg itself will be modified similarly. With these changes in mind, the "dpkg --print-gnu-build-architecture" option has been removed entirely; packages or build rules that used that string should be modified to use dpkg-architecture instead. In addition, "dpkg --print-installation-architecture" has been deprecated, please use "dpkg --print-architecture" instead which always gives the same output. During the above work, the GNU architecture string for Linux was changed from "i386-linux" to "i486-linux-gnu". This newer value is more accurate and allows for future Linux ports that don't use glibc (for example, embedded Debian using uclibc). However this will break any package that uses the value of DEB_HOST_GNU_CPU, DEB_HOST_GNU_SYSTEM, DEB_HOST_GNU_TYPE or the DEB_BUILD_* equivalents and expects to find the string "i386" or "linux" in them. You should use the new variables described above instead, as these contain fixed values that aren't directly related to the toolchain. (Obviously, if you're passing values to the toolchain through (e.g.) configure arguments, you would still use the GNU values and wouldn't be bitten by the changes). Packages using the new variables can either declare a build-dependency on dpkg-dev (>= 1.13.5), which will prevent them from being built with the sarge toolchain, or can aim for compatibility with both versions of dpkg-architecture using the following Makefile snippet supplied by Colin Watson: ----8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<---- DEB_HOST_ARCH_CPU := $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU 2>/dev/null) DEB_HOST_ARCH_OS := $(shell dpkg-architecture -qDEB_HOST_ARCH_OS 2>/dev/null) # Take account of old dpkg-architecture output. ifeq ($(DEB_HOST_ARCH_CPU),) DEB_HOST_ARCH_CPU := $(shell dpkg-architecture -qDEB_HOST_GNU_CPU) ifeq ($(DEB_HOST_ARCH_CPU),x86_64) DEB_HOST_ARCH_CPU := amd64 endif endif ifeq ($(DEB_HOST_ARCH_OS),) DEB_HOST_ARCH_OS := $(subst -gnu,,$(shell dpkg-architecture -qDEB_HOST_GNU_SYSTEM)) ifeq ($(DEB_HOST_ARCH_OS),gnu) DEB_HOST_ARCH_OS := hurd endif endif ---->8-------->8-------->8-------->8-------->8-------->8-------->8-------->8---- SELinux support --------------- Manoj Srivastava's work on implementing SELinux support directly into dpkg has now been integrated. Rather than relying on scripts to be run during the installation process, this applies security contexts internally within dpkg as the package is unpacked. If no context for the file can be found, the default context is applied. Wig & Pen source format ----------------------- The Wig & Pen ("Format: 2.0") source format is an evolutionary (rather than revolutionary) change to the current source package format. Brendan O'Dea's work on providing _unpack_ support has been integrated into dpkg-source. Support for building these formats will be added as it matures and solidifies. Existing source packages ("Format: 1.0") are supported without modification. The basics of the new format are: * Multiple upstream tarballs are supported: The orig.tar.gz is unpacked as normal, additional upstream tarballs are named orig-XXX.tar.gz and unpacked into the XXX sub-directory of the source. Thus glibc might be unpacked as: glibc-2.3.2.ds1 (from glibc_2.3.2.ds1.orig.tar.gz) glibc-2.3.2.ds1/nptl (from glibc_2.3.2.ds1.orig-nptl.tar.gz) glibc-2.3.2.ds1/posixthreads (from glibc_2.3.2.ds1.orig-posixthreads.tar.gz) * The "Debian Diff" may be replaced by the "Debian Tar": Instead of placing your changes and Debian directory as a patch against the upstream tarball in a diff.gz, you may instead ship the Debian directory as a debian.tar.gz. This is unpacked into the debian sub-directory of the source. Changes to upstream may then be stored as separate patches in the debian/patches directory, and are applied automatically (with the same rules as run-parts) to the upstream source when the package is unpacked. Thus glibc would be unpacked as: glibc-2.3.2.ds1/debian (from glibc_2.3.2.ds1-20.debian.tar.gz) * Bzip2 compression is supported as an alternative to gzip. This can be picked on a file by file basis, you might choose to compress the upstream source with bzip2 and the debian tarball with gzip to get the best results. Further improvements may be made to this format in later 1.13 releases, and as build support is added. Dpkg log file ------------- An oft-requested feature is now implemented and enabled by default. Dpkg will log all actions, package status changes and conffile decisions to /var/log/dpkg.log. The format of action log messages is: YYYY-MM-DD HH:MM:SS <action> <pkg> <installed-version> <available-version> Where <action> is one of "install", "upgrade", "remove" or "purge". The format of status change log messages is: YYYY-MM-DD HH:MM:SS status <state> <pkg> <installed-version> Where <state> includes "installed", "unpacked", "half-installed", etc. The format of conffile decisions is: YYYY-MM-DD HH:MM:SS conffile <filename> <decision> Where <decision> is the action the user decided on and is either "install" or "keep". Hopefully this will allow users to discover what got upgraded (or broken) during an APT run, aid installer debugging and many other uses. A related, but unconnected, change is that dpkg will now output errors and notification of a conffile prompt to the status-fd if being used. This work by Michael Vogt will hopefully aid authors of front-ends hide dpkg a little more from the user until libdpkg is available later down the line. Crowd Pleasers -------------- Existing Replaces are now taken into account when installing a package; this means that if A Replaces B, and B is installed when you install A, dpkg overwrites B's files without error. "dpkg -l"/"dpkg-query -l" now only limits the width of columns when used on a terminal. If used on a pipe, or to output to a file, etc. each column is as wide as the longest value with it. Fundamentally, this means that `dpkg -l | grep "really-very-long-package-name"` will work. Now that the woody->sarge upgrade can take place, dpkg no longer Pre-Depends on dselect. This means you can happily remove dselect from your system; there may be a "dpkg --purge dselect" party in your area. "dpkg-source -x" can now take an optional second argument, this is the directory name to output the source package into (instead of source-version). The dpkg package no longer supplies its own NIH implementation of md5sum, instead the coreutils version is diverted into the right place. If you're interested in where dpkg is going, vote for and attend the "Freezing HEL Over" talk/BOF/tomato-throwing I'll be giving at Debconf5; you may also wish to read the wiki at http://www.dpkg.org/ and/or join the email@example.com mailing list. Those interested in helping fix bugs should join the firstname.lastname@example.org mailing list. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
Description: This is a digitally signed message part