#29 Consolidate golang.org/x package names
Closed 4 years ago by qulogic. Opened 4 years ago by qulogic.

Currently, packages from golang.org/x/* are fairly inconsistently named:

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.

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.

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.

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)

4 years ago

Login to comment on this ticket.

Metadata