On Sun, Jul 23, 2023 at 09:03:24AM +0200, Sven Joachim wrote: > On 2023-07-23 09:37 +0300, Adrian Bunk wrote: > > > Package: libcudf-dev > > Version: 0.10-1 > > Severity: serious > > X-Debbugs-Cc: [email protected] > > > > The following packages have unmet dependencies: > > libcudf-dev : Depends: libtinfo6 (= 6.1+20181013-2+deb10u2) but > > 6.4+20230625-1 is to be installed > > Depends: libncurses-dev (= 6.1+20181013-2+deb10u2) but > > 6.4+20230625-1 is to be installed > > > > This is due to: > > > > https://salsa.debian.org/ocaml-team/cudf/-/merge_requests/2 > > > > cudf (0.10-1) unstable; urgency=medium > > ... > > [ Debian Janitor ] > > ... > > * Remove constraints unnecessary since buster (oldstable): > > + libcudf-dev: Replace dependency on transitional package > > libncurses5-dev > > with replacement libtinfo6 (= 6.1+20181013-2+deb10u2), > > libncurses-dev (= > > 6.1+20181013-2+deb10u2) in Depends. > > ... > > > > > > I haven't checked whether the replacement package names are correct, > > but the = dependences hardcoded in debian/control are clearly wrong. > > Hardcoding a dependency on libtinfo6 is also wrong, but libncurses-dev > is indeed the successor of libncurses5-dev.
I think the root cause is that the janitor did an automatic and incorrect replacement based on the transitional package in buster: Package: libncurses5-dev Version: 6.1+20181013-2+deb10u2 Depends: libtinfo6 (= 6.1+20181013-2+deb10u2), libncurses-dev (= 6.1+20181013-2+deb10u2) libncurses5-dev depending on libtinfo6 might be unnecessary since libncurses-dev already depends on it, but that doesn't make it bogus. Using = dependencies in a transitional package is unusual but not incorrect when these packages are built from the same source package. The dependency of libncurses5-dev could therefore likely be simplified to Depends: libncurses-dev but the problem is seems to that the janitor does not have a sanity check to refuse a replacement. I see two bugs in the janitor here: 1. >= or >> dependencies in the replacement are OK, = dependencies are not. <= or << dependencies should likely also be refused since they should be checked by a human. 2. Dependencies on two packages are usually a package split, automatic replacement works but might often be wrong for the different reason that it creates too many dependencies. > Cheers, > Sven cu Adrian
