Re: Not sure why e2fsprogs is BD-uninstallable on amd64?
On 09.02.2018 19:56, Theodore Ts'o wrote:
> At the moment, according to buildd dashboard for e2fsprogs[1], the package
> is uninstallable on amd64, kfreebsd-amd64, and kfreebsdi396.
>
> [1] https://buildd.debian.org/status/package.php?p=e2fsprogs
>
> The reason cited is:
>
> e2fsprogs depends on missing:
> - e2fslibs:amd64 (= 1.43.8-2)
>
> However, this doesn't make any sense to me. There are no build
> dependencies on e2fsprogs:
>
> Build-Depends: gettext, texinfo, pkg-config, libfuse-dev [linux-any kfreebsd-any] <!pkg.e2fsprogs.no-fuse2fs>, libattr1-dev, debhelper (>= 9.0), libblkid-dev, uuid-dev, m4
>
> And there with 1.43.9-1, there are no install-time dependency from
> e2fsprogs to e2fslibs (any more):
>
> Pre-Depends: libblkid1 (>= 2.17.2), libc6 (>= 2.14), libcom-err2 (>= 1.42~WIP-2011-10-05-1), libext2fs2 (= 1.43.9-1), libss2 (>= 1.34-1), libuuid1 (>= 2.16)
>
> Previously we had such a dependency:
>
> Pre-Depends: e2fslibs (= 1.43.8-2), libblkid1 (>= 2.17.2), libc6 (>= 2.14), libcomerr2 (>= 1.42~WIP-2011-10-05-1), libss2 (>= 1.34-1), libuuid1 (>= 2.16)
>
> ... but that was before e2fslibs was renamed to libext2fs2 in
> 1.43.9-1. And since e2fslibs is built as part of e2fsprogs, I'm not
> sure why this would be a dependency that would case e2fsprogs to be
> BD-uninstallable in the first place.
That was a red flag to me. It's still in unstable:
> e2fslibs | 1.43.7-1 | unstable | kfreebsd-amd64, kfreebsd-i386
> e2fslibs | 1.43.8-2 | unstable | amd64, arm64, armel, armhf, hurd-i386, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x
> e2fslibs | 1.43.9-1 | buildd-unstable | all
> e2fslibs | 1.43.9-1 | unstable | all
For some reason it's not in the cruft report[1], though. So I think you
want to request removal of the arch-specific unstable builds that are
still there. Unfortunately that sometimes happens when packages go from
arch:any to arch:all.
Interestingly enough it also just got uploaded on amd64, so I suppose
someone did something behind the scenes and forced it into building.
After all there might have been some weird interaction with the package
filtering we employ before feeding lists to dose-builddebcheck.
Kind regards
Philipp Kern
[1] https://ftp-master.debian.org/cruft-report-daily.txt
Reply to: