#915948 dak: arch:all lag from amd64 causes old binaries to disappear?

#915948#5
Date:
2018-12-08 09:19:27 UTC
From:
To:
Package: ftp.debian.org
User: ftp.debian.org@packages.debian.org
Usertags: dak

The source-only upload of perl_5.28.1-3 yesterday resulted in a mirror
push where the new arch:any binaries (perl, perl-base etc.) were in the
amd64 Packages list, but the arch:all ones (perl-modules-5.28, perl-doc
etc.) were missing altogether. This caused issues for people upgrading
their chroots, as for instance build-essential was not installable
anymore. The situation was fixed with the next mirror push.

The problem is visible in

http://snapshot.debian.org/archive/debian/20181207T214432Z/dists/sid/main/binary-amd64/Packages.xz

I assume this happened because the amd64 builds were finished three
hours before the 'all' builds, and the mirror push happened in between.

ISTR there at least used to be a check where arch:all binaries are not
exposed before the corresponding arch:any ones are built, but it looks
like the reverse is not true? In any case, even the old versions (5.28.1-2
in this case) of the arch:all binaries disappearing seems incorrect to me?

Thanks for your work on Debian,

#915948#10
Date:
2019-07-08 20:14:20 UTC
From:
To:
Control: severity -1 important

Upgrading chroots is not so much of a problem (perl will just be held
back), but creating new ones is problematic (or, as in the above case,
impossible).

Another example is

https://snapshot.debian.org/archive/debian/20180717T222551Z/dists/sid/main/binary-amd64/Packages.xz

where there is no ncurses-base present.  This is much worse than the
perl example above, since debootstrap will happily create a chroot
lacking the ncurses-base package, but without any terminfo files all
kind of breakages will happen there. :-/

For those who want to see for themselves,

# debootstrap --variant=minbase sid /whatever/dir https://snapshot.debian.org/archive/debian/20180717T222551Z

Then chroot into /whatever/dir, even bash is already "interesting" to
use with backspace and delete keys producing funny results.

Cheers,
       Sven

#915948#19
Date:
2022-10-16 20:05:19 UTC
From:
To:
This bug hit postgresql-common yesterday after the 144+nmu1 upload.
Only postgresql-server-dev-all:amd64 was present in the sid Packages
file, all arch:all packages from that source (postgresql-common and
others) were missing.

Britney was complaining pretty loudly that the binaries were missing.

One dinstall later things were in order again.

rmadison reported the packages present during that time ("source, all"),
I think, but possibly that was already after the next dinstall, before
deb.debian.org had been updated.

Christoph

#915948#24
Date:
2025-12-16 06:53:51 UTC
From:
To:
There is an argument to be made that arch:all/arch:any packages should be
copied into the Packages files even without the corresponding arch:any/arch:all
packages being built (for example because of a FTBFS): once an
arch:all/arch:any package is put into incoming.d.o it can be used to build
other source packages. At that point it should end up in a Packages file
because otherwise it will not be registered by snapshot.d.o and then a source
package built on the buildds might not be reproducible anymore as one of its
build dependencies never appeared on snapshot.d.o. Relevant MR:

https://salsa.debian.org/ftp-team/dak/-/merge_requests/298

Thanks!

cheers, josch