On 2023-07-23 10:57 +0300, Adrian Bunk wrote:
> On Sun, Jul 23, 2023 at 09:03:24AM +0200, Sven Joachim wrote:
>> On 2023-07-23 09:37 +0300, Adrian Bunk wrote:
>>
> 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.
That dependency was created by dh_link, since
/usr/share/doc/libncurses5-dev was a symlink to libtinfo6. I could have
used libncurses-dev as target of the symlink instead and thereby avoid a
direct dependency on libtinfo6 at the cost of slightly complicating
debian/rules, but that is moot now.
> Using = dependencies in a transitional package is unusual but not
> incorrect when these packages are built from the same source package.
Again, the /usr/share/doc symlink forced a strict dependency anyway.
> The dependency of libncurses5-dev could therefore likely be simplified to
> Depends: libncurses-dev
That is correct.
> 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.
Agreed.
Cheers,
Sven
