Re: binNMU or reproducible builds (choose only one)

[Santiago Vila <sanvila@unex.es>]

[ Dropping cc and moving to devel only ].

On Thu, Sep 17, 2015 at 10:26:11PM +0200, Niels Thykier wrote:
> binNMUs are much more lightweight than source-full NMUs.  Notably:
> 
>  * They are not subject to the NMU policy which involves delays
>    - These are certainly politics that could be changed, but ...

The source-full NMUs I propose for cases like this would be equivalent
for all purposes to the old binNMUs, so it would be reasonable to
treat them as such regarding delays, warnings and such.

(i.e. no delays, no warnings, they are done every time they are needed,
and the maintainer does not need to acknowledge them in the changelog
at all).

>  * Scheduling a binNMU is a simple command that involves nothing from
>    the person scheduling beyond running it.
>    - Certainly the tool could be patched/replaced, but notably, you
>      do not have to sign/upload things for this to work.

Ok. It may be worth to change the tool to do source-only uploads instead
(which, combined with the Arch: all autobuilder, should yield the
same result).

I will not claim that the change is trivial, but on the other side, if
autobuilders have special code to handle binNMUs, once that the new
tools is in place, the old code could be dropped, which would simplify
things a little bit, I guess.

> [...]
> The use of dh_installdocs --link-doc between arch:any and arch:all has
> up to now always been "broken" (read: binNMU unsafe).  If we were to
> replace the binNMU implementation with something that ensured lock-step
> versions between arch:all and arch:any packages, it could start work.

Well, from the point of view of build-reproducibility, what is broken is the
whole binNMU idea.