GNU bug report logs - #54097
go importer does not honor multi-module repositories

Previous Next

Full log

View this message in rfc822 format

From: "Timo Wilken" <guix <at> twilken.net>
To: "wolf" <wolf <at> wolfsden.cz>
Cc: 54097 <at> debbugs.gnu.org
Subject: bug#54097: [PATCH] import: go: Handle subpackage versioning correctly.
Date: Mon, 22 May 2023 21:11:34 +0200

Hi wolf,

On Sun May 21, 2023 at 11:54 PM CEST, wolf wrote:
> Please give the github.com/Azure/go-autorest/tracing <at> v0.6.0 a go.  My code
> failed on it, and (assuming I applied the patch correctly) your does as well.
> Here are reproduction steps to make it easier for you (please tell me if I did
> something wrong):

I don't think you did anything wrong there.

That's an issue I've run into in the past as well, though it seems to be a bug
in the Go build system, not the importer (and in my patch I only touch the
importer).

> I will not pretend to have a full grasp on how (guix build-system go) works,
> however my debugging lead me to the observation that it tries to unpack two
> dependencies into one file system tree overlayed on top of each other.  I think
> the current way (GO111MODULE=off) of building of golang packages does not play
> very well with well, go modules.

Fair enough! I don't know much about Go -- I don't write software in it, I
just want to package some stuff written in it; in my case, that's
Matrix-related programs.

> Either the build system needs to be smarter about unpacking dependencies (and
> doing it in a correct order), or we should start using go modules for the builds
> (it can still be down offline, just the dependencies are in different paths).
> The second approach is what I wanted to explore, but did not get to it yet (and
> likely will not for a month or two).

Your second approach sounds sensible!

If I can find the time and motivation to dig in to this, I might have a go as
well... But if you get anything working, that would be much appreciated! :)

Cheers,
Timo

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.