ng0 transcribed 2.5K bytes:
> Mark H Weaver transcribed 0.9K bytes:
> > Hi Leo,
> > 
> > leo@famulari.name (Leo Famulari) writes:
> > 
> > > lfam pushed a commit to branch master
> > > in repository guix.
> > >
> > > commit 478ebb31a96955fc03fcea55a4432976ddb49319
> > > Author: Leo Famulari <leo@famulari.name>
> > > Date:   Wed Oct 11 20:22:32 2017 -0400
> > >
> > >     gnu: Add go-github-com-templexxx-reedsolomon.
> > 
> > On this, and a great many other packages, you've included "github-com-"
> > in the package names.  I think this is a very bad idea.  For one thing,
> > we should not advertise, promote, or enhance the lock-in of GitHub, and
> > this policy does all three.  Sometimes a maintainer decides to change
> > their hosting arrangements.  When they do so, we should simply be able
> > to update some URLs in one package definition.  We should not have to do
> > a global find/replace on the package name and alert our users to update
> > their profiles and OS definitions.  That contributes to lock-in.
> > 
> > What do you think?
> > 
> >       Mark
> 
> I think Leo just followed the upstream conventions here, where it is
> named after the path the go module ends in.
> If we decide not to name the package like this, we might break expectations.
> So when we break expectations, what are the alternative naming schemes
> we could pick for go packages that'll still make sense to people
> using Go?

One idea could be:

    go-templexxx-reedsolomon
    
so just remove the hoster from the package name.
I'm not using Go, so I don't know if this will make any sense
or cause potential namespace issues.
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://dist.ng0.infotropique.org/dist/keys/
https://www.infotropique.org https://ng0.infotropique.org