Am 16.07.26 um 08:40 schrieb Simon Josefsson:
> Two more "strange" packages, where upstream doesn't ship any go.mod at
> all.  There are two problems here: 1) the source files are duplicated,
> once in v2/ and then again in v2/v2, this doesn't match upstream source
> code, and 2) the go.mod is generated into v2/v2 but not in v2/.

Hi Simon,

you're right, both packages show some strange behaviour. This is
probably due to the fact that both are from 2020, when Go 1.13 was the
current compiler version. The idea of Go modules was rather new back
then, and IIRC some conventions of today's standards weren't yet in
place. For example, the go source code in the top level directory and
the go source code in the v2 directory are identical. Only the v2
directory does have a go.mod file.

The XS-Go-Import-Path: github.com/jcmturner/dnsutils/v2 is probably
false and needs to read "github.com/jcmturner/dnsutils", without the v2
appended. This is really counter-intuitive, unfortunately.

But as I've said, this is due to upstream's unconventional handling of
go modules from 6 years ago.

I'm not sure what the best way to resolve this would be. Regarding the
module-aware build within Debian, I suspect that it might be good to
generate a go.mod file for the top level directory and run go mod tidy
on it, then add it as a patch. But this is quite a lot of overhead,
maybe there's a better solution for this.

Regards,
Tobias

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to