dpkg in etch+1, changes from ubuntu
FYI:
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
agree ?
The changelog entry, which summarises all of the differences between
Ubuntu's latest dpkg, and the latest one in sid, is below.
Ian.
dpkg (1.13.24ubuntu1) feisty; urgency=low
* Merge from debian unstable.
Remaining differences from Debian to Ubuntu follow:
Miscellaneous fixes:
* 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:
lib/showpkg.c
lib/tarfn.c
src/configure.c
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:
* References:
http://lists.debian.org/debian-devel/1997/10/msg00643.html
https://wiki.ubuntu.com/PackageDependencyFieldBreaks
* 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.
Decisions made:
* 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
for Conflicts.
* <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 <iwj@ubuntu.com> Thu, 23 Nov 2006 20:15:09 +0000
Reply to: