Re: dh_golang fails because a package got completely disabled with tags
Thanks for explaining what’s going on here. I think this actually makes for a compelling case to add explicit build tag handling. I’m still of the opinion that upstream should ship software in such a state that build tags shouldn’t be necessary, but the existing way to specify build tags clearly doesn’t work correctly, so adding an explicit option to dh-golang sounds reasonable to me.
Do you have an opinion on how to implement this handling?
I could see introducing a DH_GOLANG_BUILD_TAGS environment variable as a way to a) simplify exisiting debian/rules files and b) providing an consistent interface to cover both 'dh build' as well as 'dh_golang' steps. I know that you expressed your concerns against this approach before, but I wonder if this thread maybe made you reconsider?