On Mon, 08 Jan 2024 at 15:01:11 -0800, Steve Langasek wrote:
> If a maintainer ignores the NMU and drops the rename, they'll be introducing
> a new library transition again on 32-bit archs. Won't they also be caught
> again in binary NEW, for those packages that don't have the same runtime
> library package name in experimental?
To have a concrete example of this, I think you are saying:
- NMU of src:foo renames libfoo0 to libfoo0t64
- maintainer ignores NMU and uploads, effectively renaming libfoo0t64
back to libfoo0
- you want the maintainer's upload to get stuck in NEW
I am not a ftp team member, but if I understand NEW correctly, this
will only trigger a new trip through NEW if the ftp team have already
removed libfoo0 from the overrides file ("decrufting"), which is not
done immediately, only after libfoo0 has not been built by src:foo for
a little while.
If libfoo0 exists in testing and/or stable, I'm not sure whether that
prevents the ftp team's processes from removing it from the overrides file.
If it does, then a new, maintainer upload of libfoo0 will certainly not be
considered NEW, and the safety-catch that you are thinking of will not be
effective.
smcv
