Control: severity -1 important On 2018-12-08 11:19 +0200, Niko Tyni wrote:
> Package: ftp.debian.org > User: ftp.debian....@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. 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). > The problem is visible in > > > http://snapshot.debian.org/archive/debian/20181207T214432Z/dists/sid/main/binary-amd64/Packages.xz 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. > 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? Cheers, Sven
