Currently, packages from golang.org/x/* are fairly inconsistently named:
golang.org/x/*
golang.org/x/arch golang-x-arch golang.org/x/build golang-x-build golang.org/x/crypto golang-googlecode-go-crypto golang.org/x/debug golang-x-debug golang.org/x/net golang-googlecode-net golang.org/x/oauth2 golang-googlecode-goauth2 golang.org/x/perf golang-x-perf golang.org/x/sync golang-x-sync golang.org/x/sys golang-github-golang-sys golang.org/x/text golang-googlecode-text golang.org/x/time golang-github-golang-time golang.org/x/tools golang-googlecode-tools
We should pick a consistent scheme and rename these, especially since googlecode is dead now.
FWIW, I like the golang-x-foo scheme since it best reflects the import path in a concise way, in my opinion.
golang-x-foo
Here you see the difference between “modern” Fedora go packages, that use a macro to map the import path to the rpm name, and pre-existing Fedora packages, where the mapping was done in a less strict manual way.
And some of those are old enough they were renamed upstream, and Fedora didn't reflect the renaming (not upstream first :().
It's not hard to fix technically, it only takes using the naming macro like recent Fedora packages, and writing the corresponding obsoletes rules (a lot of it could probably even be scripted). But it requires someone to go through the new package process. The "new review on rename" rule made an easy tidying fix expensive.
I can do the reviews if I don't do the renaming.
Here you see the difference between “modern” Fedora go packages, that use a macro to map the import path to the rpm name, and pre-existing Fedora packages, where the mapping was done in a less strict manual way. And some of those are old enough they were renamed upstream, and Fedora didn't reflect the renaming (not upstream first :().
All of those should be caused by the rename/move of the upstream.
As you are noting, those are probably existing due to that renaming package in Fedora is fairly costly on the maintainer(s).
I also expect that these names would be consistent when using the macros, so this issue is more of a nudge to the maintainers of those packages that they should rename, both because that's the name created by the macro and because it makes the distro look bad from the inconsistency.
This has now been fixed with the macro refresh by @eclipseo.
Metadata Update from @qulogic: - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.