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

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
agree ?

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:

  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:
       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:
  * 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: