Hello folks,
So, following the ticket to the packaging-commitee:
https://pagure.io/packaging-committee/issue/1307
The summary of the meeting is the following:
We discussed this during today's meeting, and there was consensus for two
things:
we don't like that package Name is controlled by a macro where its
implementation can change and could lead to situations where source package
name != dist-git package name
we don't like the situation we have ended up with wrt/ the Go package naming, since
the guidelines around compat packages have been around when the diverging scheme for Go
packages was devised, and don't want this to set a precedent for "ignore the
guidelines for long enough and it will become accepted practice"
Our suggestions are:
If the package names would continue to use a hyphen as separator for the version specifier
("-vN"), we would like the package suffix to be "-vN" as well.
If you would like the current Go naming practices to remain in place, we
would consider documenting the exception for using a hyphen as a separator for
this purpose.
For the first option, I think no changes to the Naming Guidelines would be
needed. For the second option, an exception would need to be documented in
either the Naming Guidelines, or in the Go Packaging Guidelines directly.
(if I am mis-characterizing something in this summary, please correct me).
Maxwell said:
If you would like the current Go naming practices to remain in place, we
would consider documenting the exception for using a hyphen as a separator for
this purpose.
I think that's the best way forward.
Carl said:
Right, this is one of the reasons I'm hesitant to make that change at this point. We
could always add a flag to enable the "new" scheme, but I'm not sure that's
worthwhile.
Rather than changing the macro implementation, we can just change the guidelines to say
maintainers SHOULD NOT use %{goname}. This is already the case for "well-known
application" like containerd, etcd, hugo, and more. Libraries would switch from
using %{goname} to an explicit name that follows the package naming guidelines. That
wouldn't make the process of requesting a new dist-git repo any easier, but it would make
the spec file changes trivial. At some point after all usage of %{goname} is absent from
rawhide spec files, the macro could be changed to trigger an error if it's used.
I would prefer we pick the option that makes the most technical sense, rather than the
one that has the most inertia. I'd be open to a "going forward" policy, letting
non-compliant package names age out over time (or get converted gradually as people get
to them).
What I propose:
- New packages should adopt the correct guidelines, no hyphen before version.
- Older packages should be kept as is for compatibility, i.e. an exception based on
existing import path.
- In go2rpm we do not use the %goname macro but hardcode the result of it, so if goname
change, the Name: field doesn't.
- Change the Go packaging guidelines to remove reference to %goname
- Progressively replace Name: %{goname} by the hardcoded value while the
package are updated.
As such:
- in go-rpm-macro, I make a list of 130-ish goipath exception list. If it is not in the
list, the goname is computed according to official guidelines.
- in go2rpm, same thing, and instead of putting %goname in Name: field, we put the computed
value.
Here are the merge requests:
- go-rpm-macros: https://pagure.io/go-rpm-macros/pull-request/56
- go2rpm: https://pagure.io/GoSIG/go2rpm/pull-request/31
Testing is done here:
https://copr.fedorainfracloud.org/coprs/eclipseo/macros-fix3/builds/
/!\ I'd like your opinion as soon as possible so we can unstuck packages in
fedora-scm-requests /!\
I do not want to wait for the next meeting in a week.
Please vote, propose other solutions here or in the Pagure SIG ticket:
https://pagure.io/GoSIG/go-sig/issue/53#comment-877603
Best regards,
Robert-André
_______________________________________________
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/golang@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
