Bug#887664: [debhelper-devel] Bug#887688: debhelper: empty build of src:ck

[Niels Thykier]

Simon McVittie:
> On Fri, 19 Jan 2018 at 06:29:18 +0200, Adrian Bunk wrote:
>>  debian/rules build
>> make: Nothing to be done for 'build'.
> 
> I think this is probably the same thing as openal-soft bug
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887664>. Both packages
> have:
> 
> * a build/ directory in the upstream source
> * ".PHONY: build" in d/rules
> * no explicit build target in d/rules, only the usual "%:" implicit rule
> 
> My theory is that this regressed as a result of
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880840
> having been fixed.
> 
> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880840#20,
> James Cowgill wrote:
>> Make ignores implicit rules (like %: dh $@) for phony targets.
> 
> So the maintainers of these packages thought they had solved the problem
> by adding ".PHONY: build", but when they moved from an explicit build
> target to dh minimized style, they broke that assumption; but then their
> packages built successfully anyway, because they were using a version of
> debhelper that had #880840, so the contents of the build sequence were
> redundantly invoked. We can see this happening in reproducible-builds'
> builds of ck and openal-soft on buster, with:
> 
>> [...]
> 
> (It looks as though the entire build for openal-soft was done under
> fakeroot as a result of this, which isn't great for robustness.)
> 

Indeed; prior to debhelper/11.1 they were failing the "should"
requirement of having the "build" target build the package.  It would
happen anyway because the "binary" target (called under fake(root))
would incorrectly inline the build-arch and build-indep sequence.

Obviously, buildds would be completely unaffected as they never use
"build" or "binary".

> Debhelper maintainers: do you consider this to be something that should
> be addressed in debhelper, or in the affected packages like ck and
> openal-soft?
> 
>     smcv
> 
> [...]

I am not comfortable adding additional layers of complexity to the
makefile parsing if I can at all avoid it.  In all cases, packages
relying on this will eventually have to fix it.
  The question now is: How many packages are affected by it?  If it is
sufficiently low, it might be worth doing the clean up now to simplify
packaging in general.  But in worst case, we will have to revert for now
and reintroduce this to compat 12.

Thanks,
~Niels