FS#72074 - [gcc-go] Split package into separate compiler and gotools packages
Attached to Project:
Arch Linux
Opened by env (ENV25) - Wednesday, 08 September 2021, 15:42 GMT
Last edited by freswa (frederik) - Friday, 11 February 2022, 18:25 GMT
Opened by env (ENV25) - Wednesday, 08 September 2021, 15:42 GMT
Last edited by freswa (frederik) - Friday, 11 February 2022, 18:25 GMT
|
Details
Description:
Currently this package provides the gccgo compiler (usr/bin/gccgo) and some go tools (usr/bin/{go,gofmt}). It is not required to provide usr/bin/{go,gofmt}. One can use usr/bin/go from [community] with usr/bin/gccgo from this package. (I extracted and repackaged this package locally, removing usr/bin/{go,gofmt}, to test this) $ go build -compiler gccgo But currently you cannot install both go [community] and gcc-go [core] at they same time because they both provide usr/bin/{go,gofmt} and conflict. Also the only way one can use gccgo after installing go [community] is uninstalling and reinstalling. $ go build # gc compiler # pacman -Rs go # pacman -S gcc-go $ go build # gccgo compiler # pacman -Rs gcc-go # pacman -S go To fix this you could split this package into gcc-go [core] and gccgo [core]. The gccgo package should have most of the files the current package does and should provide usr/bin/gccgo. The gcc-go should depend on gccgo and should additionally provide usr/bin/{go,gofmt} so that current installs are not broken. Users of the go [community] package can install gccgo [core] only and others can install gcc-go [core] normally. The split packages names can be something else. I haven't seen anyone else talk about this issue, I might be the only one needing this. |
This task depends upon
Closed by freswa (frederik)
Friday, 11 February 2022, 18:25 GMT
Reason for closing: Won't implement
Additional comments about closing: In general we don't do a lot of splitting and as long as gcc-go is not on par with upstream go, I don't want to add more maintenance burden. We might reconsider this later though.
Friday, 11 February 2022, 18:25 GMT
Reason for closing: Won't implement
Additional comments about closing: In general we don't do a lot of splitting and as long as gcc-go is not on par with upstream go, I don't want to add more maintenance burden. We might reconsider this later though.