[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bits from the dpkg maintainer



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 debian-dpkg@lists.debian.org mailing list.  Those interested in
helping fix bugs should join the debian-dpkg-bugs@lists.debian.org
mailing list.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: