bluefin-dx tracking issue

[bketelsen]

in order to serve as a replacement for the -dx experience we need the following included in a single sysext:

• [x] docker
• [ ] gcc & general build toolset
• [ ] lxd
• [ ] incus
• [x] vscode
• [ ] jetbrains
• [ ] kcli
• [ ] docker-compose
• [ ] dive
• [ ] flux
• [ ] helm
• [ ] ko
• [ ] minio-client
• [ ] kubectl
• [ ] kind
• [ ] kubectx
• [ ] kubens
• [ ] fonts
• [ ] devpod
• [ ] virt-*
• [ ] qemu-*

Some of these are packaged by and maintained upstream by Fedora. I think those should be "installed" in the sysext as-is.

Others require some custom build steps and bring in dependencies that Fedora doesn't carry. Those should be installed in a custom prefix. I've proposed /usr/bluefin in Discord, but I think that's thinking too small, so I'm thinking /usr/ublue to make this a little more general feeling. (even though it's just an alpha/Proof Of Concept it's never bad to shoot for the stars)

Tools installed in the custom prefix will not be available without modifying PATH variables. This is intentional, a user of the system won't even see the -dx tools without enabling them. This prevents -dx tools from masking system provided tools, and prevents third party dependency libraries from appearing in LD CPP PKG* type paths.

How to build

There are at least two obvious paths for building sysexts.

• The current state of this repo represents the "quick way". Make a directory that acts roughly like a chroot, put files in there, then squashfs them into a disk image.
• mkosi from v20+ now supports building sysexts directly.

These are two very different recipes for the same outcome. The "quick way" feels very fast and loose with fewer guardrails. The mkosi way is far more rigid and structured, with a steeper learning curve.

We should explore both, especially from the CI/CD perspective. I'm not sure mkosi + Fedora and Github Actions are a good combo, but that's just because I haven't seen it done yet. The "quick way" is very GHA friendly, the first commits to this repo show using a podman container to build and compress the tools, which we've already shown in the UBlue universe to be a very effective way to build and distribute.

Other notes to track

• [ ] custom built software with .desktop files need to be added to the appropriate XDG* paths
• [ ] custom prefix bin directory needs to be added to GDM paths

[m2Giles]

Login (from VT) does not pass environment variables sourced from login shell to systemd user session.

GDM does this.

So if we are placing something to set a path in /etc/profile.d does systemd user session need to know this path or not? Will there be a different behavior for a user?

I'm assuming no, but should be something we check as well.