I've been struggling with a Go application that's currently not packaged under Guix.
-
I've been struggling with a Go application that's currently not packaged under Guix.
The importer would seem to generate around 300 Go package definitions. Then there's at least a handful of cases where the importer fails and definitions would need to be created by hand. Plus the definitions need to be tested and those that fail to build would need to be manually fixed. Rather laborious, it'd seem.
I'm starting disliking Go, but then doubt creeps in. Is it Go, specifically, or is it just that this time I'm unlucky and *I* have to do the packaging work?! Spoiled free software brat or facing a real example of dependency hell?
-
@fabionatali I'm speaking from a place of ignorance, but if there are steps in the build process that can fail randomly, it sounds like an upstream problem.
What are those generated package definitions? Why are they failing anyway? Why are there 300GB ?! o.O
-
@mariusor Hi, the "definitions" I mentioned are the way applications get packaged under my distributions, Guix. This particular app I was looking at would seem to require around 300 new definitions (as opposed to GB) for as many dependencies. Sometimes automatically generated definitions may fail to build (i.e. to process correctly and generate a binary output), thus requiring manual intervention. Gulp! It seems a lot of work.
-
@fabionatali is guix not using the Go methods of building? Theoretically you can build a static package and the go toolset downloads everything for you without needing a separate "definition" for every dependency... Sorry, if I'm missing the mark, I'm very unfamiliar with guix.