| 1 |
On Mon, Apr 20, 2020 at 03:23:15PM -0400, Michael Orlitzky wrote: |
| 2 |
> > Are you volunteering to do the work to package go packages? The people doing the work generally get to decide how that work gets done, and which approach they would like to take. The upstream situation makes it very labour-intensive to do the work in a the way you are proposing (many packages would end up with hundreds to thousands of packages in the tree). Separating everything out in to separate packages will just increase the maintenance load exponentially, with no gains as go upstreams version lock all their dependencies. |
| 3 |
> > |
| 4 |
> |
| 5 |
> I'm volunteering to work on one or two small Go packages. Can I convert |
| 6 |
> the eclass to use dynamic linking? Can I start replacing your packages |
| 7 |
> with my own if I need them as dependencies? I suspect not, and that's |
| 8 |
> one of many reasons why "having things in ::gentoo does not affect |
| 9 |
> anyone who does not use them" is bullshit. |
| 10 |
|
| 11 |
As one of the maintainers of the go-module eclass, I'm all ears, but |
| 12 |
keep a couple of things in mind. |
| 13 |
|
| 14 |
First, I have yet to see an upstream go-based build system that uses |
| 15 |
dynamic linking for go libraries. No one does it. they all statically |
| 16 |
link everything. This alone probably means you'll have to patch every |
| 17 |
upstream build system you find. |
| 18 |
|
| 19 |
Another issue is the sheer number of dependencies that a single go |
| 20 |
package would pull into the tree. |
| 21 |
For example, dev-vcs/cli-0.6.3, which looks like a small enough |
| 22 |
package, has 65 dependencies. sys-apps/kubernetes-1.18.2, a bigger package for |
| 23 |
sure, has 246. So, the worst case you are looking at here is over 300 |
| 24 |
dependencies, and this is just for two packages. The only way this |
| 25 |
number would come down is if these packages happened to share exact |
| 26 |
dependencies since you can't really unlock the versions. |
| 27 |
|
| 28 |
and, yes, gccgo is out there, but no one writes for it. I have yet |
| 29 |
to see an upstream that supports using it. So, if you go that route, |
| 30 |
you are looking at patching build systems. |
| 31 |
|
| 32 |
Your proposal seems to completely go against how the go ecosystem operates, |
| 33 |
but if you can come up with a proof-of-concept for how it would work |
| 34 |
without forcing a lot of busy work on us that would never get accepted |
| 35 |
upstream, I'll take a look. |
| 36 |
|
| 37 |
William |
Archives