nim commented on the pull-request: `Replace Go internals with go/build` that you are
following:
``
The v2 is module versioning. That's something we need to support to have working Go
packaging. It's good that your PR starts picking it up when the previous code does
not.
However you are right that just doing it that way is going to break things. It needs
changes in other parts of `golist` *and* in the macro code (and the current go-rpm-macro
code should be in a good enough shape to allow those changes but that ’s not what it in
Fedora).
Looking at how `github.com/cespare/xxhash` handled the module transition, assuming it is
representative of the conversion of a real-world codebase to modules, here is the list of
the things I see needing doing (paper analysis, real work implementation and testing is
needed)
- we have the new module descriptors. That means `golist` needs to include the `go.mod`
file as part of the project files, otherwise it will not end up in the -devel package and
rpm will (rightfully) ignore it when generating deps
- then once the `go.mod` file is in the devel package we need to check the golist call
that generates the package provides actually sees it (should probably just work with the
code in go-rpm-macros and will almost certainly fail in some case with the code in Fedora
because some of the approximations I fixed this year and which are still in the Fedora
macro code will definitely hurt module parsing)
- then we have the fact that modules break the identity between the URL and the import
path. The code is still at `https://github.com/cespare/xxhash` but the logical name is now
`github.com/cespare/xxhash/v2`. No matter this is a case that is handled nicely by
go-rpm-macros, that just means you need to declare `github.com/cespare/xxhash/v2` as
`goipath` and `https://github.com/cespare/xxhash` as `forgeurl`
- the module says v2 depends on v1 which means you need a separate v1 spec and package
with just `github.com/cespare/xxhash/` `goipath` (and be careful to pull from the V1
banch not the v2 one)
- but, what happens when a single git repo ships several `go.mod` files with a logical
name that has nothing to do with the URL path ? I suspect things will break badly. the
latest go-rpm-macros code is a lot more flexible, but it still assumes some form of
identity between the filesystem layout and the import layout. How badly will this identity
break with modules? I have no idea.
- and then you have the version qualifiers in the module files, we need to map them rpm
side one way or another
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/pull-request/17