Bug 1715534 - Adopt new Go Packaging Guidelines
Summary: Adopt new Go Packaging Guidelines
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Changes Tracking
Version: 31
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Robert-André Mauchin 🐧
QA Contact:
URL:
Whiteboard:
Depends On: 1684930
Blocks: 1727674
TreeView+ depends on / blocked
 
Reported: 2019-05-30 15:02 UTC by Ben Cotton
Modified: 2019-08-14 20:07 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-14 20:07:23 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ben Cotton 2019-05-30 15:02:42 UTC
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.

Comment 1 Jakub Čajka 2019-06-28 07:46:03 UTC
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?

Comment 2 Jakub Čajka 2019-06-28 07:48:03 UTC
(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.

Comment 3 Nicolas Mailhot 2019-06-28 10:51:02 UTC
(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.

Comment 4 Nicolas Mailhot 2019-06-28 10:55:21 UTC
(and, BTW, not SIG has the power to endorse anything, when there's no one willing to to the work that this anything implies)

Comment 5 Jakub Čajka 2019-06-28 10:59:12 UTC
(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.

Comment 6 Jakub Čajka 2019-06-28 11:02:11 UTC
(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.

Comment 7 Nicolas Mailhot 2019-06-28 13:19:50 UTC
(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.

Comment 8 Jakub Čajka 2019-06-28 13:50:03 UTC
(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.

Comment 9 Robert-André Mauchin 🐧 2019-07-02 20:29:44 UTC
(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.

Comment 10 Fabio Valentini 2019-07-09 16:24:38 UTC
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

Comment 11 Elliott Sales de Andrade 2019-07-09 17:24:40 UTC
Add Obsoletes and retired those old packages.

Comment 12 Jakub Čajka 2019-07-16 06:56:33 UTC
(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.

Comment 13 Robert-André Mauchin 🐧 2019-07-16 16:36:06 UTC
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

Comment 14 Ben Cotton 2019-08-13 16:50:00 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 15 Ben Cotton 2019-08-14 17:56:01 UTC
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.

Comment 16 Robert-André Mauchin 🐧 2019-08-14 19:53:03 UTC
(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?


Note You need to log in before you can comment on or make changes to this bug.