On Mon, Feb 15, 2021 at 01:52:59AM +0100, Andreas Henriksson wrote: > On Sun, Feb 14, 2021 at 01:05:11PM +0000, Colin Watson wrote: > > How about this approach instead? Given the choice between a > > packaging-only change and one that requires another patch against > > upstream, I have a slight preference for the packaging-only change as > > long as it's basically reasonable, which I think this is. It just > > overrides configure's automatic detection and tells it that sha2.h isn't > > available. Builds cleanly and doesn't seem to incur any new direct > > dependencies. > > Whatever works and feel free to choose the way you as maintainer > prefers as far as I'm concerned! :)
Right, I'll go ahead and upload this. > FWIW I make similar choices myself, but my definition of preferred > solution is a bit more complicated. Nothing is ever as permanent > as something temporary. It's not uncommon to see a temporary > hack be forgotten about and then not be dropped when it's > no longer needed, just to come back later and bite you in the ass. > So while I agree with your rule in general, I go for patches when > there's a big chance that the patch will stop apply when upstream > fixes this. Then it's hard to miss that it should be dropped when > the package is updated the next time.... However there's no guarantee > that will happen with my patch, so it's really up to you to go > with your gut feeling. Yeah, I agree with your more nuanced version of this too. FWIW, I think your patch in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982705#25 is correct (even if I prefer to take a different approach as a workaround for the packaging) and could be forwarded upstream. Would you mind doing that? I normally prefer people to forward their own patches where possible so that there's no doubt about copyright/licensing intent or whatever. -- Colin Watson (he/him) [cjwat...@debian.org]
