* On 2024-09-06 at 18:46 BST, Thomas Klausner wrote:
On Fri, Sep 06, 2024 at 02:05:39PM +0100, Jonathan Perkin wrote:Ultimately with our GCC infrastructure there are two main paths forward: * Make it really simple, remove all of the confusing complexity, and put the burden on the user to configure mk.conf to make it work correctly for their environment. My "gcc-selection" branch aims towards this.I think you're talking about https://github.com/NetBSD/pkgsrc/compare/trunk...TritonDataCenter:pkgsrc:feature/gcc-selection/trunk It has about 40 commits, can you summarize what the plan was?
It's been a while, but I think the majority of it was removing cargo-culted bits and anything else that no longer makes sense, and making the separation between native and pkgsrc GCC much clearer, so that none of the pkgsrc GCC logic was loaded for USE_NATIVE_GCC=yes.
Plus a bunch of documentation, mostly so that it was clear to me what was going on, as once you start diving into it you quickly lose track of what's happening due to the complexity.
I'm thinking that we should perhaps switch to a model where we bootstrap including a compiler (perhaps allowing to choose any of the gcc packages, or just the newest one), and if a package wants a newer version than that bootstrapped (or the native) one, then the package is marked as broken.
Yes, this is what I'd do (though not at bootstrap time), but I think that due to the NetBSD release model this is unlikely to be accepted, given it would mean that you'd no longer be able to ship lots of packages for the most recent release (any package that has GCC_REQD+=11 or newer).
-- Jonathan Perkin - mnx.io - pkgsrc.smartos.org Open Source Complete Cloud www.tritondatacenter.com