trim EESSI set for gentoo overlay

[trz42]

Goal: get a more minimal compat layer Ideas/Tasks

• [ ] remove build dependencies (Go, make, ninja, ...)
• [ ] add command suggested by Bart

[bedroge]

Also see: https://github.com/EESSI/compatibility-layer/issues/139.

Relevant Slack message from Bart:

At the meeting last week there was some talk about the compatibility layer having too many packages. I looked a bit into stacked prefix (two prefixes, where the second depends on the first) but that wasn’t quite what I was looking for. What you can do after a fresh bootstrap is to run emerge --depclean --with-bdeps=n this will remove around 100 packages including Meson, Ninja, Rust, but also the autotools. So here was my exercise in minimalism:

• fresh Gentoo bootstrap, ./startprefix, remove /usr/bin and other system paths from $PATH

• add lmod and easybuild via the ebuilds on zugaina (http://gpo.zugaina.org/sys-cluster/easybuild)

• run emerge --depclean --with-bdeps=n

• then run eb GCCcore-11.3.0.eb with the filter deps from EESSI. That almost worked, except for M4 that was now missing. After adding M4 it builds ok.

• So the filter deps for EESSI is now (https://raw.githubusercontent.com/EESSI/software-layer/main/configure_easybuild):

DEPS_TO_FILTER=Autoconf,Automake,Autotools,binutils,bzip2,cURL,DBus,flex,gettext,gperf,help2man,intltool,libreadline,libtool,Lua,M4,makeinfo,ncurses,util-linux,XZ,zlib of those the minimal build-depend stripped Gentoo prefix with Lmod and EB has these: DEPS_TO_FILTER=binutils,bzip2,cURL,libreadline,Lua,ncurses,util-linux,XZ,zlib So that’s one extreme right there. Not sure what you want to take from that; certainly removing the build-deps but adding the things you want to keep explicitly is an option?

[bedroge]

And another relevant message from Guilherme:

My recommendation as long time Gentoo user (and what I do myself in my own system) is to emerge what you want as usual, emerge temporary things with emerge --oneshot, then at the very end just run emerge --clean to remove temporary stuff and build dependencies. I wouldn't go unmerging stuff from the @system set, as that may get you compat layer into a broken state. (edited)

If you really want to drop stuff that we have in the system set, then you may want to create your own profiles, as that will give you such control, but I think you should only do that as last resort.

You can safely remove stuff from the world set, though, then run emerge --clean to get rid of unnecessary stuff. To keep the system up to date, I run emerge ‐NDuavt world

You can also try --keep-going to let emerge do the most it can, even when one or more packages fail to build

[boegel]

@trz42 @bedroge Can this be closed (for 2023.04)?

[bedroge]

@trz42 @bedroge Can this be closed (for 2023.04)?

For 2023.04 we have just removed a given list of packages from the resulting compatibility layer. Perhaps it's still good to investigate if we could/should trim it even more by running for instance the command that Bart suggested (which will remove quite a lot of packages).