[Debian-med-packaging] Bug#1113407: pizzly: diff for NMU version 0.37.3+ds-9.1

Adrian Bunk bunk at debian.org
Tue Oct 21 13:49:48 BST 2025


On Tue, Oct 21, 2025 at 10:46:05AM +0200, Andreas Tille wrote:
> Hi Adrian,

Hi Andreas,

> Am Mon, Oct 20, 2025 at 10:56:38PM +0300 schrieb Adrian Bunk:
> > > I think this will not be accepted anyway.  I do not see any reason to
> > > ask him for canceling.
> > 
> > FTR:
> > I do not have a problem with canceling an NMU, and any DD could cancel
> > an NMU from DELAYED when there is a reason (and the maintainer upload
> > is not anyway faster so that the NMU will just be rejected).
> 
> Thank you for confirming this.  I admit I simply consider it an extra
> manual step that has no real value once there is a higher version right
> inside the archive, thought.  Please correct my if you might see this
> differently.

in the reject case there is no reason to cancel.

I was thinking of the case where the NMU is in DELAYED/2 and the 
maintainer says "I will fix it when I have time next weekend".
In that case the maintainer could/should cancel it.

>...
> > There is even precedent of maintainers doing +exp1 uploads for some 
> > time every time they are doing an upload to unstable for maintaining
> > an experimental-only change until it is ready for unstable.
> 
> I admit I prefer the ~exp1 way ... but this is probably a matter of
> taste / team policy.

Personally I'd prefer ~exp1 for something that is supposed to be the 
next upload to unstable soon, and +exp1 (or +test1 or +simde) for 
"let's try something" experiments.

But yes, how experimental is used is for the maintainer to decide.

> BTW, as a general note regarding the CMake 4 bugs:  I prefered adding
> -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to override_dh_auto_configure target
> in d/rules over patching.  The effect is more or less the same but
> works without an additional patch that might need maintenance later.
> Do you have any reason to prefer a patch?

When a new upstream version fixes it a patch will get dropped during
the upgrade, but -DCMAKE_POLICY_VERSION_MINIMUM will stay forever.

Your argument is that removing the patch later is work, and my argument 
is that removing the patch later is better than still having a stale
-DCMAKE_POLICY_VERSION_MINIMUM in debian/rules in 25 years.

Neither argument is particularly strong.

>...
> Kind regards
>     Andreas.

cu
Adrian



More information about the Debian-med-packaging mailing list