profiles/default/linux/make.defaults has the entry below. > # make sure toolchain has sane defaults <toolchain@gentoo.org> > USE="${USE} fortran openmp" I don't think it makes sense to enable these globally. We already have IUSE="+fortran +openmp" on sys-devel/gcc via toolchain.eclass. Some profile archaeology: The fortran entry dates back to 2005. https://gitweb.gentoo.org/archive/repo/gentoo-2.git/commit/?id=463daeaf9ecf296f584d9e0cc593fbb9f406823b The openmp entry dates back to 2007. https://gitweb.gentoo.org/archive/repo/gentoo-2.git/commit/?id=8552e276e3f20cc71bfbd3ddb3c8c1314046515d These was copied to a new profile structure in 2008. https://gitweb.gentoo.org/archive/repo/gentoo-2.git/commit/?id=85990dfb635cf03ab433c73a7f928efdb9adf22e
Assuming we are in agreement on removing the entry, do we need a news item for this?
How about, if we do this, we do it with the 23.0 profiles? Makes things a bit more controllable...
I suppose that would be fine.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8189b4b48c25dbd7b330b51b53f9023cdbbb29ec commit 8189b4b48c25dbd7b330b51b53f9023cdbbb29ec Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2023-02-19 16:56:07 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2023-02-20 18:02:41 +0000 profiles: move USE="fortran openmp" from default/linux to releases/17.0 This is an obsolete profile entry from the days when IUSE defaults did not exist. Bug: https://bugs.gentoo.org/890999 Signed-off-by: Mike Gilbert <floppym@gentoo.org> profiles/default/linux/make.defaults | 5 +---- profiles/releases/17.0/make.defaults | 5 ++++- 2 files changed, 5 insertions(+), 5 deletions(-)
Should be all set on this for 23.0.
Unfortunately this creates a regression for our use case. We have (and had for years) custom profiles that are managed in git (base and per machine). They are based on Gentoo profiles and the inheritance (also based on inheritance of normal Gentoo release profiles) is: /etc/gp/machine/profiles/init /var/db/repos/gentoo/profiles/base /var/db/repos/gentoo/profiles/default/linux /var/db/repos/gentoo/profiles/default/linux/amd64 /etc/gp/base/profiles/features/clear /var/db/repos/gentoo/profiles/arch/base /var/db/repos/gentoo/profiles/features/multilib /var/db/repos/gentoo/profiles/arch/amd64 /var/db/repos/gentoo/profiles/releases /var/db/repos/gentoo/profiles/releases/17.0 /var/db/repos/gentoo/profiles/arch/amd64/no-multilib /etc/gp/base/profiles/features/base /etc/gp/base/profiles/arch/x86-64 /etc/gp/machine/profiles/features/machine /etc/gp/machine/profiles/machine Please notice /etc/gp/base/profiles/features/clear that removes USE (and some other settings) added in /var/db/repos/gentoo/profiles/default/linux. Then we inherit arch profiles (since we don't want to remove USE from them because it's useful and non-controversial). Then we set our own settings (global and per machine). Your change re-added fortran and openmp for us because it moved it from place where we expect such controversial/legacy defaults to release where we don't. Is there any other way to do it that won't clutter release profiles with legacy?
Sorry, but Gentoo isn't responsible for profiles defined outside of gentoo.git. If you can propose a an alternate solution I would be happy to review it.
Let's not confuse being friendly to out-of-tree profiles with supporting/being responsible for them. The real question is: should Gentoo put legacy/controversial decisions into default/linux only or also into release profiles? If release profiles are good place for such decisions then I guess authors of out-of-tree profiles need to deviate further from Gentoo profiles by not inheriting release profiles directly and doing their work themselves. I am not a huge fan of that since it means they would need to keep their forks in sync with Gentoo by hand. And we want it to still be Gentoo, even if customized for easier central management of many servers or other needs. Suggestions: 1. Revert this change and then (*) stop enabling these USE flags by default in any profile. Almost nobody really needs them and if they need they know how to turn them on. Of course some grace period before (*) + news would be nice. 2. Revert this change and then wait for new release profiles (and disable these USE flags in new release profiles for now) and then give out-of-tree profiles time to migrate to new release and then apply this patch again if needed (and stop disabling these USE flags in new release profiles since they won't inherit them any longer from defaults/linux). 3. Not easy but perhaps right: stop doing such work in default/linux or release profiles. Instead create "bare" release profiles that won't need to be further cleaned by out-of-tree profiles and "defaults" profiles that inherit these base profiles and add "defaults" for users that want them. Then out-of-tree profiles (or power users) can skip defaults and inherit base profiles to apply their own defaults. 4. Make out-of-tree profiles first class citizen in Gentoo. Central change management is the core of devops and automation today and in Gentoo we mostly don't need any ansible or whatever because we have ingenious tool called profiles. We just are not promoting their use outside of official profiles for some strange reason. :-)
I'm not going to revert the change. I'm not going to try to establish Gentoo policy via this bug report. You can raise the issue on the gentoo-dev mailing list if you wish to establish a policy of some sort. I am happy to review alternate patches that would satisfy the goal of not setting USE="fortran openmp" in the 23.0-derived profiles, while keeping it set in the 17.x profiles. Setting USE="-fortran openmp" is not acceptable under any circumstance.
I am not a Gentoo developer so I won't try to establish it's policies. I don't know the procedures, probably are not allowed to do many things, etc. I, as a Gentoo user, am reporting a problem with your fix to this bug. I am sorry but you are a Gentoo developer. You know the procedures and you have all the accesses needed. If you have doubts about what should be done and what is the right/acceptable way to do it in Gentoo then I kindly ask you to mail whatever Gentoo ML and try to establish whatever policies are needed. Before such random fixes will transform Gentoo profiles into even worse unholy nightmare of mess with overrides to overrides to support "compatibility" with strange legacy stuff and break (probably much more legitimate) use cases (too). If not, out-of-tree profile authors or power users will soon have to fork whole profile tree and merge Gentoo changes by hand filtering problematic deltas or put even more dedicated hacks into their profiles just to hand-clean loads of new strange problems. I am prepared to do it but it's sad. It's really sad that one can't simply inherit current release profile to have small sane server/VM/container system (that doesn't break every other month because of new "fixes" to old but current releases). It's really sad that I had to inject "cleanup" profile in the middle of Gentoo profiles to do things like USE="-*" to achieve small, sane environment and not break arch profiles by adding USE="-*" later. And it's even sadder that now even that is not enough given fixes like in this bug. EOT from my side, do whatever you want, I will put loads of new overrides in my profiles if needed
Status quo is that Gentoo profiles are not maintained with any sort of external third party custom profiles in mind. If you want that changed, you will need to put in some effort. It's not a cause I'm going to champion for you.
It's worth noting that releases/17.0 really doesn't define anything other than the USE setting I just moved there. You won't lose anything by removing it from your custom profile inheritance chain.
The key is: "right now". I think they did in the past (and I am maintaining my profiles for many years and plan to do so for many years). Release profiles can (and should!) any time introduce other settings than random USE ((un)masks, flags, /usr policy, ...), possibly very important (as in 'not breaking my numerous systems') settings for people that, for example, didn't migrate yet to new release. So yes, I can probably fork by skipping releases/17.0 and inheriting releases right now but, as with all forks, I would be potentially missing important settings later. And I believe that profiles are about such important settings and not random policies that random devs are adding at random times inspired by random choice from desktop/server/HPC/set-top box/whatever else they think of at the moment of commit - just like fortran and many others were added in the past. And that is the one of the two reasons why I am not "using profiles in the blessed way" and instead "inheriting": 1. I am cleaning them of unneeded and unstable policy and other bloat. 2. I am using inheritance on top of current release proflles to easily support many similar (but often not 100% identical) systems in a DRY way. First one should be provided by Gentoo by default, second should be considered normal usage because from Gentoo dev's point of view it changes nothing vs. "the blessed way".
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=94d882482714698d6d9b765920cd26bbe849336d commit 94d882482714698d6d9b765920cd26bbe849336d Author: Sam James <sam@gentoo.org> AuthorDate: 2023-04-26 04:06:21 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-04-26 04:09:40 +0000 toolchain.eclass: don't enable openmp by default for >= 13 This should be set in profiles going forward, not in toolchain.eclass. Bug: https://bugs.gentoo.org/890999 Signed-off-by: Sam James <sam@gentoo.org> eclass/toolchain.eclass | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
