Hey, > > Rephrasing this just to ensure I'm understanding it correctly: you're > suggesting to move _everything_ that uses Go into its own overlay. Let's > call it gentoo-go for the sake of the example. > > If the above is accurate, then I hard disagree.
Yes, that was the suggestion, you understood it correctly. > > The biggest package that I have that uses Go is docker (and accompanying > tools). Personal distaste of docker aside, it's a very popular piece of > software, and I don't think it's fair to require all the people who want > to use it to first enable and sync gentoo-go before they can install it. It could be enabled by default for everyone, and people would have the choice to disable it or mask everything except what they are using in that case, so the extra user toil could be avoided by a creaful rollout. I'm not saying it would be an elegant solution though. > > And what about transitive dependencies? Suppose app-misc/cool-package is > written in some language that isn't Go, but it has a dependency on > sys-apps/cool-util which has a dependency on something written in Go. > Should a user wanting to install cool-package have to enable the > gentoo-go overlay now too? Even though app-misc/cool-package would look > like it doesn't need the overlay unless you dig into the deps. This is however a valid point, something I did not consider. Any reverse dependencies (i.e. packages in main portage tree depending on gentoo-go) would be anithetical to the overlay philosopy (the other direction of dependencies is okay though). This invalidates my separate overlay suggestion, consider it withdrawn. However I think that my other points still stand, until someone convinces me otherwise. > > Not a dev, just a user who really likes Gentoo :) Thanks for your perspective, it was a valueable observation. :) > > - Oskari > Cheers, Zoltan
signature.asc
Description: PGP signature