Bug#1041758: libcudf-dev is not installable due to bogus janitor change

[Adrian Bunk <bunk@debian.org>]

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: team+janitor@tracker.debian.org
> >
> > 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