dpkg in etch+1, changes from ubuntu
As part of our merge at the start of our release cycle, I've just done
a review of the current differences between Debian's version (1.13.24)
and what I've just uploaded into Ubuntu's development branch.
I think all of the changes are ones that Debian should take, but they
should generally wait until after etch. There are a few changes that
might be nice for etch but stability is probably more important than
long-overdue bugfixes at this point.
Most of the changes are already represented in existing Debian bug
reports, with patches attached. The main exceptions are:
* The bug with the full implementation of Breaks doesn't have the
right version of the patch. (#379140)
* There are some spurious file overwrite conflicts with symlinks
to directories; this misfeature is not reported in the Debian BTS
at all atm for some reason (oversight by me, probably).
There's a vague description at https://launchpad.net/bugs/22340.
I could spend the effort to dig out separate patches for these but I
think the right answer is for Debian to take all of the changes
currently in Ubuntu as soon as etch is forked off. Does everyone
The changelog entry, which summarises all of the differences between
Ubuntu's latest dpkg, and the latest one in sid, is below.
dpkg (1.13.24ubuntu1) feisty; urgency=low
* Merge from debian unstable.
Remaining differences from Debian to Ubuntu follow:
* Fix for Debian #378003 (multiple deconfigurations).
* mlib contains m_strdup (part of the fix for Debian #379028).
* dpkg: add missing newline to an error message.
(LP 29729, submitted upstream as Debian #390914.)
* Fix formatting of these files:
src/archives.c (function quote_filename only)
to conform to the rest of dpkg by running them through
expand -t2 (and in the last case using M-x indent-rigidly once).
As discussed on debian-dpkg. Submitted upstream as Debian #375711.
* dpkg: describedepcon uses more l10n-friendly approach.
(LP 63744, submitted upstream as Debian #390916.)
* dpkg-source: respect g+s and umask when extracting.
(LP 51468, submitted upstream as Debian #390915.)
The new behaviour is that the only thing which matters about the
permissions specified in the archive is whether an object has execute
permission for anyone, as for chmod =X. Set-id (of files and
directories) and read/write permissions from the archive are ignored.
Permissions are determined by the umask; group ownership and
directory-setgid according the usual filesystem policies.
* Don't consider it a file conflict if the package contains
a symlink to a directory where another package already contains the
same symlink/directory and the existing and new symlinks point to the
same place. (Launchpad 22340. Apparently not reported upstream yet.)
Implementation of Breaks:
* Manpages mention Breaks: deb-control.5, dpkg-query.1, dpkg.1.
* Support for Breaks in dpkg-source, dpkg-gencontrol et al.
* Support for Breaks in the code in dpkg.
* Breaks is ignored by dselect.
* Specifying Breaks: <virtual package> is fairly meaningless
without versioned Provides but to make versioned Provides easier
in the future we support it fully.
* We do not transitively deconfigure things when we deconfigure
due to Breaks, just as we don't do so when we deconfigure due
to removal due to Conflicts (see also Debian #378009).
* Just as for deconfiguration due to Conflicts, we don't deconfigure
Essential packages without --force-remove-essential.
* We aren't willing to deconfigure more than one package as a result
of a single element of a Breaks, just as we aren't willing to
remove more than one package as a result of a single element of
a Conflicts. (Note that this can only occur due to virtual
packages so it can be worked around by specifying the individual
real packages instead.)
* We're happy to deconfigure a package that's on hold even if
afterwards, due to Breaks, there might not be a way to reconfigure it.
(This is analogous to the situation where we install a package which
no longer satisfies the dependencies of an on-hold package; it's not
clear what the right answer is.)
* We invent a new --force-breaks which does much the
same as --force-conflicts.
* --ignore-depends works for Breaks even though it doesn't work
* <deconfigured's prerm> deconfigure in-favour <installing> <ver>
as well as
<deconfigured's prerm> deconfigure in-favour <installing> <ver> \
removing <conflictor> <ver>
and of course the corresponding
<deconfigured's postinst> abort-deconfigure in-favour <installing> <ver>
-- Ian Jackson <firstname.lastname@example.org> Thu, 23 Nov 2006 20:15:09 +0000