'dpkg --predep-package' can output pre-dependencies that are not
installable without also installing some other dependencies. This causes
problems for debootstrap which now uses --predep-package to help resolve
pre-dependencies of included packages that aren't in Priority: required.
(Ian said at DebConf that it was OK for debootstrap to use this, and
furthermore that the problem I'm seeing is a bug in --predep-package
that he'd like to fix.)

It's not entirely clear to me what the correct fix is, given the
possibility of circular Depends. I suspect that --predep-package needs
to output multiple Packages stanzas in some cases; this in turn would
require fixes in /usr/lib/dpkg/methods/disk/install since it expects
only a single stanza at the moment.

The attached available and status files demonstrate the problem. With
these, 'dpkg --predep-package' prints the Packages stanza for xml-core
(due to a Pre-Depends from docbook-xml), which depends on sgml-base
which is not installed.

If you want a more real-world reproduction case, see #487908 and use
revision 59820 of
svn://svn.debian.org/svn/d-i/trunk/packages/debootstrap with the
attached patch applied to remove the workaround I applied for this bug.
You can then run, as root:

  DEBOOTSTRAP_DIR=`pwd` ./debootstrap --include docbook-xml sid /chroot/dtest http://ftp.debian.org/debian `pwd`/scripts/debian/sid

The output will terminate with:

  W: Failure trying to run: chroot /chroot/dtest dpkg --force-overwrite --force-confold --skip-same-version --install /var/cache/apt/archives/xml-core_0.12_all.deb

By the way, I realise that this is a little-used feature of dpkg and
indeed that it's marked internal. However, it was remarkably useful to
avoid having to write a Pre-Depends resolver in debootstrap, so I'd
really appreciate it if it kept working!

Thanks,

tags 539133 + patch
thanks

[This message was written a few weeks ago on a train and I'm just
 sending it now, having dug it out ...]

I have investigated #539133 and I think the patch below should fix it.

The previous algorithm for --predep-package made a number of
assumptions about the dependency structure which are no longer even
nearly true.  In particular, it assumed that no package would
Pre-Depend on an other package which would Depend on anything in
circumstances where this would matter.  Nowadays we even have Depends
cycles amongst the packages required to be configured for satisfying a
Pre-Depends and suchlike complications.  For example:
  docbook-xml P xml-core D sgml-base D perl D perl-modules D perl D libgdbm3
where P = Pre-Depends and D = Depends.

As a result of this it is no longer possible to satisfy
pre-dependencies by installing a single package at a time.  In the
example above, at the very least perl and perl-modules must be
configured in the same dpkg run to allow dpkg's dependency cyle
breaker to operate.

Therefore this revised --predep-package function can print _several_
Packages file stanzas.  If this happens you should feed dpkg _all_ of
the relevant .debs.

To avoid having to write a proper cycle detector I have made the
entirely arbitrary assumption that no more that 20 levels of
dependency (before cycles) will be relevant to a pre-dependency.  If
we exceed this limit someone should be shot.

This patch is against dpkg 1.14.25 (sorry).  I have tested it with the
test case available and status files supplied by Colin in the bug
report and also with a few other simple situations.

The arrangements with the goto in depcon.c are rather ugly; I wouldn't
really want to do it like that but I didn't want to make the match
more textually intrusive.  It would be better to do something like
  enum istobes depended_istobe(...appropriate arguments...) {
    if (itb == itb_preinstall)
      return dep->type == dep_predepends ? itb_normal : itb_installnew;
    return itb;
  }
and then call that in each of the two relevant places,
instead of switching directly on possi->ed->clientdata->istobe
and provider->up->up->clientdata->istobe.

Ian.

Hi!

It seems you attached a patch for another package.

regards,
guillem

tag 539133 - patch
thanks

Hi!

Removing the tag for now.

thanks,
guillem

In 2009 it seems I attached the wrong file to my email.  Here is the
right file.