Using a very basic configuration for simple-cdd, I can't build a stretch
image:

  # cat > cdd.conf
  debian_mirror=http://deb.debian.org/debian
  security_mirror=http://security.debian.org/
  dist=stretch
  profiles=test
  ^D
  # mkdir -p profiles
  # echo nano > profiles/test.packages
  # build-simple-cdd --conf cdd.conf
  [...]
  WARNING Found uninstallable packages in /root/cdd/tmp/mirror/dists/stretch/main/binary-amd64/Packages:
  WARNING   output-version: 1.2
  WARNING   report:
  WARNING    -
  WARNING     package: libpam-systemd
  WARNING     version: 232-25+deb9u8
  WARNING     architecture: amd64
  WARNING     status: broken
  WARNING     reasons:
  WARNING      -
  WARNING       missing:
  WARNING        pkg:
  WARNING         package: libpam-systemd
  WARNING         version: 232-25+deb9u8
  WARNING         architecture: amd64
  WARNING         unsat-dependency: systemd (= 232-25+deb9u8)
  WARNING
  WARNING   total-packages: 364
  WARNING   broken-packages: 1

libpam-systemd is version 232-25+deb9u8 in stretch, but 232-25+deb9u9 in
stretch/updates, so 232-25+deb9u9 should of course be selected.

If I explicitely add libpam-systemd to my list of packages, everything
works as it should:

  # echo libpam-systemd >> profiles/test.packages
  # build-simple-cdd --conf cdd.conf
  # echo $?
  0

When running with --debug, you see 232-25+deb9u8 being downloaded from
stretch in both cases. However, when libpam-systemd is listed in
test.packages, 232-25+deb9u9 is also later downloaded from
stretch/updates, and used to correctly satisfy the dependency.

FTR, here's the status for systemd at the time of this writing:

 stable: 232-25+deb9u8
 stable-sec: 232-25+deb9u9

If this changes in the future, and there is a need to reproduce, I
believe it could be achieved by pointing simple-cdd to the proper
snapshots.d.o mirrors.

Cheers,

I haven't confirmed exactly, but this is not terribly surprising; the
dependency resolver doesn't do any versioned dependency checking, it
simply loops through trying to find more depends/recommends and then
stops once no new packages are found.

Maybe just doing 1 or more extra passes in the loop would fix it, making
sure all packages are updated... I might try and reproduce this kind of
issue and see if that wouldn't fix it. Though I have my doubts, as the
package should already be added to the list of packages to
include in the repository...


The proper thing to do is use dose-distcheck or another more
sophisticated tool to actually resolve the dependencies; that's what's
used to check if there are missing dependencies, but actually using them
to resolve the dependency tree up-front might very well result in a more
reliable and quite possibly faster process all around.

At the moment, that's unfortunately the recommended workaround for these
situations. It particularly comes up with multiple repositories, such as
the primary repository and the security repository, or when pulling
packages from backports.


live well,
  vagrant

I am experiencing the same kind of issue with 0.6.7 on buster building a
buster image. Thanks to this report I was able to determine why
libgnutls-openssl27 was breaking for me.

Then I also discovered that this problem also silently affects some
packages without actually causing any breakage that would get noticed.
Simple-cdd just simply leaves some packages with old versions. E.g. I
found out that simple-cdd is leaving my image with outdated e2fslibs and
libcomerr2 packages because the security repo has old versions of those.

I came up with a different workaround that I'd recommend over what was
recommended above. If you list the affected packages in test.downloads
(instead of test.packages) then it still works around this bug but
without marking the resulting package installation as explicitly
selected. At least, for me it seems to.