Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

[Patrick McLean]

On Mon, 20 Apr 2020 15:23:15 -0400
Michael Orlitzky <mjo@g.o> wrote:

> On 4/20/20 2:58 PM, Patrick McLean wrote:
> >>
> >> You keep saying that, but the fact that dev-go/* is filled with trash
> >> that has your name on it prevents anyone else from doing a better job.
> >>
> > Ad-hominen attacks are unwarranted, please refrain from them. I challenge you to find *anything* in dev-go/* with my name on it.
>
> You quoted me one sentence prior saying that it's the Go ebuilds that
> are trash and not anyone personally. But OK, I should have said "Sony
> Interactive Entertainment" there instead of "you."

My co-workers are not the only ones adding/maintaining go packages in the tree, please do not single out any groups, and let's all work to make Gentoo the best it can be.

>
> > 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.
> >
>
> I'm volunteering to work on one or two small Go packages. Can I convert
> the eclass to use dynamic linking? Can I start replacing your packages
> with my own if I need them as dependencies? I suspect not, and that's
> one of many reasons why "having things in ::gentoo does not affect
> anyone who does not use them" is bullshit.
>
Please do not make backward-incompatible changes to existing eclasses. If you would like to make a new go eclasss (say go-dynamic.eclass) then go ahead, I am certainly not going to stop you. As was said elsewhere in the thread, there is no policy against having a second version of a package in the tree. If the second version is truly better, then the other packages can be moved over to depending on it instead, and the original package can be moved or last-rited.

The current method of packaging go packages tries to strike a balance between maintainability, following upstream, and something that is compatible with ebuilds. If you have a better way to do things, we are not going to block you from trying, but we are also not going to necessarily adopt it if working with it would be orders of magnitude more work. We all have limited time to work on Gentoo stuff.