On Sat, 2026-02-07 at 13:58:22 +0100, Santiago Vila wrote:
> On Sat, Feb 07, 2026 at 01:15:32PM +0100, Stephen Kitt wrote:
> > On Sat, 07 Feb 2026 08:47:45 +0100, Simon Josefsson <[email protected]>
> > wrote:
> > > Nebula requires golang 1.25 or later (for some crypto stuff, compilation
> > > fails with 1.24 [1]), and I solved this by adding 'golang-1.25-go' as a
> > > Build-Depends and added
> > > 
> > > export PATH := /usr/lib/go-1.25/bin:$(PATH)
> > > 
> > > to debian/rules.  This works but it is ugly.  It will do the wrong thing
> > > when 1.26+ becomes the default, keeping this package stuck on 1.25.
> > > 
> > > Is there a more future proof pattern to use for this situation?
> > > 
> > > I suppose this isn't a new situation, but I didn't run across how to
> > > solve it before.
> > 
> > How about
> > 
> > Build-Depends: golang-go (>= 2:1.25~)
> 
> That's future-proof, but afaik not "present-proof" because the current
> golang-go package in unstable is still at version 2:1.24~2.
> 
> If you don't mind that the package is not built at all until
> golang-go is updated in unstable, I think that's good enough.
> It's like uploading to delayed queue, except that it's not the upload
> what it's delayed but the build itself (until it can happen).

I guess an alternative which should (in theory) work now and in the
future could be:

  Build-Depends: golang-go (>= 2:1.25~) | golang-1.25-go

Although I don't recall exactly the behavior of buildds when it comes
to build dependency alternatives and its reduction/stripping, and
whether it takes uninstallable ones into account or not. Maybe you
might need to swap their order for now?

Thanks,
Guillem

Reply via email to