This is a tracking bug for Change: Adopt new Go Packaging Guidelines For more details, see: https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines The current Go packaging guidelines have been in a draft state for several years now, and they do not reflect the current practices from the Go SIG. As a result of new RPM macros developed by Nicolas Mailhot, the Go SIG wishes to formally adopt new Go Packaging Guidelines, which aim at automation, reliability and simplicity.
Old macros stack has supported transparent distribution wide default compiler switch and possibility for selected package to build with they preferred compiler(while still allowing using all features of the macros stack), both realized via compiler meta-package. This is most important for simplifying the bootstraping of the Go compiler and new architectures, avoiding need to import binary packages or any other obscure ways. And also allows transparent switch of the default Go compiler(on selected arches distro wide). How is this handled in the new stack?
(In reply to Ben Cotton from comment #0) > This is a tracking bug for Change: Adopt new Go Packaging Guidelines > For more details, see: > https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines > > The current Go packaging guidelines have been in a draft > state for several years now, and they do not reflect the > current practices from the Go SIG. As a result of new > RPM macros developed by Nicolas Mailhot, the Go SIG wishes to > formally adopt new Go Packaging Guidelines, which aim at automation, > reliability > and simplicity. I have just noticed this. For the record this is not a change that is endorsed by the Go SIG. This is endeavor conducted/proposed/executed by some members of it but it is not endorsed by it.
(In reply to Jakub Čajka from comment #1) > Old macros stack has supported transparent distribution wide default > compiler switch and possibility for selected package to build with they > preferred compiler(while still allowing using all features of the macros > stack), both realized via compiler meta-package. No they didn't https://koji.fedoraproject.org/koji/buildinfo?buildID=1139492 The only thing that Fedora has been shipping for several years is definition files for the Google Golang compiler. And no one complained or noticed meaning no one used the gcc-go files. So please do not claim the new guidelines or macros regressed or broke anything that was working before their adoption. It was not working. It was not even shipped. Now it could, technically, be possible to resurrect something that works with gcc-go, but without someone that wants it enough to make it work, uses it and checks it continues to work, it will bitrot like the previous attempt.
(and, BTW, not SIG has the power to endorse anything, when there's no one willing to to the work that this anything implies)
(In reply to Nicolas Mailhot from comment #3) > (In reply to Jakub Čajka from comment #1) > > Old macros stack has supported transparent distribution wide default > > compiler switch and possibility for selected package to build with they > > preferred compiler(while still allowing using all features of the macros > > stack), both realized via compiler meta-package. > > No they didn't > https://koji.fedoraproject.org/koji/buildinfo?buildID=1139492 > > The only thing that Fedora has been shipping for several years is definition > files for the Google Golang compiler. And no one complained or noticed > meaning no one used the gcc-go files. > I have implemented it and used on several occasions, so I can state that you are out right not saying the truth here. > So please do not claim the new guidelines or macros regressed or broke > anything that was working before their adoption. It was not working. It was > not even shipped. > I'm asking how are you implementing this feature. > Now it could, technically, be possible to resurrect something that works > with gcc-go, but without someone that wants it enough to make it work, uses > it and checks it continues to work, it will bitrot like the previous attempt.
(In reply to Nicolas Mailhot from comment #4) > (and, BTW, not SIG has the power to endorse anything, when there's no one > willing to to the work that this anything implies) I don't disagree with this statement, but you(change proposers) have been, put it mildly, saying that this change is representing the will and agreement of the Go SIG, when it is not as we have not agreed on it or in other matters even voted on.
(In reply to Jakub Čajka from comment #5) > (In reply to Nicolas Mailhot from comment #3) > > (In reply to Jakub Čajka from comment #1) > > > Old macros stack has supported transparent distribution wide default > > > compiler switch and possibility for selected package to build with they > > > preferred compiler(while still allowing using all features of the macros > > > stack), both realized via compiler meta-package. > > > > No they didn't > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1139492 > > > > The only thing that Fedora has been shipping for several years is definition > > files for the Google Golang compiler. And no one complained or noticed > > meaning no one used the gcc-go files. > > > > I have implemented it and used on several occasions, so I can state that you > are out right not saying the truth here. https://koji.fedoraproject.org/koji/buildinfo?buildID=1139492 No ggc-go compiler definition here. Can not break something not built in Koji and not made available to Fedora users.
(In reply to Nicolas Mailhot from comment #7) > (In reply to Jakub Čajka from comment #5) > > (In reply to Nicolas Mailhot from comment #3) > > > (In reply to Jakub Čajka from comment #1) > > > > Old macros stack has supported transparent distribution wide default > > > > compiler switch and possibility for selected package to build with they > > > > preferred compiler(while still allowing using all features of the macros > > > > stack), both realized via compiler meta-package. > > > > > > No they didn't > > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1139492 > > > > > > The only thing that Fedora has been shipping for several years is definition > > > files for the Google Golang compiler. And no one complained or noticed > > > meaning no one used the gcc-go files. > > > > > > > I have implemented it and used on several occasions, so I can state that you > > are out right not saying the truth here. > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1139492 > > No ggc-go compiler definition here. Can not break something not built in > Koji and not made available to Fedora users. That it is not used at the moment doesn't mean that it doesn't have a use.
(In reply to Jakub Čajka from comment #1) > Old macros stack has supported transparent distribution wide default > compiler switch and possibility for selected package to build with they > preferred compiler(while still allowing using all features of the macros > stack), both realized via compiler meta-package. This is most important for > simplifying the bootstraping of the Go compiler and new architectures, > avoiding need to import binary packages or any other obscure ways. And also > allows transparent switch of the default Go compiler(on selected arches > distro wide). How is this handled in the new stack? I have no idea, we've always used a tingle compiler as far as I remember, any other one was before my time. %gobuild has always used "-compiler gc", we never had the possibility to switch since then.
Some of my packages got renamed, but the old packages were neither retired nor obsoleted by the new packages: - golang-github-AudriusButkevicius-go-nat-pmp -> golang-github-audriusbutkevicius-nat-pmp - golang-github-oschwald-geoip2-golang -> golang-github-oschwald-geoip2 - golang-github-oschwald-maxminddb-golang -> golang-github-oschwald-maxminddb - golang-github-sasha-s-go-deadlock -> golang-github-sasha-s-deadlock
Add Obsoletes and retired those old packages.
(In reply to Robert-André Mauchin from comment #9) > (In reply to Jakub Čajka from comment #1) > > Old macros stack has supported transparent distribution wide default > > compiler switch and possibility for selected package to build with they > > preferred compiler(while still allowing using all features of the macros > > stack), both realized via compiler meta-package. This is most important for > > simplifying the bootstraping of the Go compiler and new architectures, > > avoiding need to import binary packages or any other obscure ways. And also > > allows transparent switch of the default Go compiler(on selected arches > > distro wide). How is this handled in the new stack? > > I have no idea, we've always used a tingle compiler as far as I remember, > any other one was before my time. %gobuild has always used "-compiler gc", > we never had the possibility to switch since then. Not really, we have been using both gc and gcc-go and there has been facilities to accommodate this. It is rather unfortunate that you are not considering this at all. So my questions basically boils down to. How do I switch singular package to other compiler? How do I switch architecture to other compiler? How do I switch distribution to other compiler? Could you please address and document these questions/use cases? Bit to the side note how do I get list of all packages that require Go compiler(pull it in to the BR)? Old abstraction is gone without any notice and nearly no package requires golang directly.
Why do you needinfo me on that? I'm not the one able to answer you on the macro stack, I haven't got a hand in that. I still haven't seen any single example of the use of gcc-go. > > Bit to the side note how do I get list of all packages that require Go > compiler(pull it in to the BR)? Old abstraction is gone without any notice > and nearly no package requires golang directly. Filter on go-rpm-macros
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
We have reached the 'Code Complete (testable)' milestone in the Fedora 31 release cycle. If your Change is in a testable state, please set the status to MODIFIED. If this Change will not be ready for Fedora 31, please set the version to rawhide. The 100% code complete deadline is Tue 2019-08-27.
(In reply to Ben Cotton from comment #15) > We have reached the 'Code Complete (testable)' milestone in the Fedora 31 > release cycle. If your Change is in a testable state, please set the status > to MODIFIED. If this Change will not be ready for Fedora 31, please set the > version to rawhide. > > The 100% code complete deadline is Tue 2019-08-27. The Change is completed in its entirety, shall I close this bug?