Hi Mark, Mark H Weaver <m...@netris.org> skribis:
> Leo Famulari <l...@famulari.name> writes: > >> On Fri, Oct 13, 2017 at 01:12:32PM -0400, Mark H Weaver wrote: >>> l...@famulari.name (Leo Famulari) writes: >>> > 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. >> >> Please don't suggest that I made a policy to promote or enhance GitHub >> "lock-in". Please keep reading for more information on why the packages >> are named this way. >> >>> 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. >> >> These packages are libraries written in the Go programming language. Go >> libraries are referred to by their "import path" [0], which is a string >> intended to uniquely identify a particular software implementation. >> >> As I wrote in the commentary on the go-build-system (part of the commit >> series being discussed), import paths are based on the URL of the >> software. A package hosted at https://github.com/leo/foo has an import >> path of 'github.com/leo/foo'. In Go, this is the library's name. >> >> These import paths are the sole mechanism by which Go software is >> uniquely referred to by humans and the Go compiler. It is even baked >> in to how dependencies are organized on disk. > > Thanks for the explanation. I find this very disturbing, but I > acknowledge that this lock-in is caused by Go itself, and that there's > probably not much that we can do about it. Oh well. I withdraw my > objection to these package names. I agree this naming scheme isn’t great, but indeed, that’s what Go gives us. Besides, Leo gave us 3 weeks to comment on <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28586>. Thus, I believe your message should have been framed as a suggestion for improvement rather than “please fix this mistake”. Thanks, Ludo’.
