Hi,

I would like lintian to complain a bit more about Replaces.

Correct uses of Replaces
========================

The most common way to use Replaces is matching it up with Breaks as
this is recommeded by policy. Another use (also detailed by policy) is
matching it up with Conflicts. A lesser known, but also frequent use
(thanks to David Kalnischkies) is combining versioned Replaces with
precluding Depends.

I want lintian to not moan about any of these.

Debatable uses of Replaces
==========================

Sometimes, Replaces are used with a << version constraint but without
matching them up with Breaks nor Conflicts. This can be useful for
taking over non-essential files from a package (e.g. splitting
documentation from a library). Such cases are still broken if you try to
reinstall the replaced package, but that's not a frequent use and having
less Breaks is beneficial to upgrade paths.

I think it is best for lintian to not moan about any of these unless we
grow consensus that we need to do something about it.

Bad uses of Replaces
====================

The remaining Replaces are thus unversioned and not matched up with
Breaks nor Conflicts. In these case, one could remove the replaced
package and later install it again. While the janitor is able to
eventually delete versioned Replaces, it cannot assist with cleaning up
unversioned ones. Finally, Replaces pose a vital role in the /usr-merge
transition as they can be broken when moving files from / to /usr, so we
want to reduce the use of Replaces to the cases that really need them.

For these reasons, I think that this third class of Replaces really is
harmful enough to the project that it is worth fixing them. In a lot of
cases, I expect that these Replaces are leftovers from the last decade
and we can probably just drop them. In other cases, we can add a version
restriction and improve reasoning about it.

I hope you agree with this reasoning. I've discussed this with a number
of participants on the Debian Reunion Hamburg 2023 and with some people
on IRC. I think what I am presenting here is close to consensus.

I'm also attaching a patch to implement the proposed check.
Unfortunately, neither me nor gregoa nor carnil were able to please
perlcritic (which for some reason is complaining about unrelated code
and we couldn't understand what it is complaining about), so this patch
currently fails one test.  Would you be able to figure out why
perlcritic is mad at this patch?

Thanks in advance

Helmut

Helmut Grohne dixit:
binary packages, e.g:

Depends: openjdk-8-jre (>= ${source:Version}),
  openjdk-8-jdk (>= ${binary:Version}),
  ${misc:Depends}
Replaces: openjdk-8-jdk (<< 8u20~b26-1~)

Also false positive:

Replaces: intel-rng-tools, rng-tools
Breaks: rng-tools (>= 5migratf), rng-tools (<< 5migrate)
Conflicts: intel-rng-tools

bye,
//mirabilos

Hi Thorsten,

Yes, this is the kind of fpos I was mentioning as expected.

This is *not* a false positive, but a real issue. It replaces any
rng-tools, but breaks only a subset. This would have to be fixed to
either drop the version constraint from Breaks (probably wrong) or add
it to Replaces. Can you handle that?

Helmut

Helmut Grohne dixit:

No, because the not-broken subset Depends on rng-tools-debian.
(It’s a transitional package.) So, while it cannot be seen by
“just” inspecting rng-tools-debian, all possible combinations
are covered.

(Also, the transition is done and rng-tools is gone.)

bye,
//mirabilos