Bug#982705: openssh: FTBFS: sha2.h:57:16: error: redefinition of ‘struct _SHA2_CTX’
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) [cjwatson@debian.org]
Reply to: