Add a sysext for vim-huge

[jsalatiel]

There are several cases when the user needs to edit k8s yamls inplace directly on the master nodes and having syntax highlighting and advanced formatting of vim available is a nice feature since the default vim of flatcar have those disabled.

[chewi]

We have just discussed whether we might want to leverage existing Gentoo packages for this instead. We could potentially do this in such a way that avoids dependence on system libraries (besides glibc) either by still statically linking or by placing the dynamic libraries within the sysext. I could look into this soon, but I don't mind accepting this in the interim.

[jsalatiel]

Hi @chewi , will this be accepted?

[chewi]

I have no objections, but I'd want someone else to look over it. I'm not familiar with sysext building yet.

[pothos]

FYI, the build process of the extensions in this repo is supposed to be fast, avoiding compilation if we can (that's the reason one build recipe was not included in the official repo releases so far).
One can bundle existing distro binaries (e.g., from a Docker image) with one of these helper scripts:
https://github.com/flatcar/sysext-bakery?tab=readme-ov-file#flix-and-flatwrap - for choosing one way and making it work one needs to know what paths vim relies on at runtime.

That said, I'm not reviewing things here now and someone else has to decide what to do with this PR.

[xinity]

IMHO sysext should not be considered as the next package manager, so perhaps vim as an editor that exists in every linux distribution might not fit here.

just sharing my point of view, no harm :)

[mnbro]

@pothos @xinity Do you have a resolution for this? Would @jsalatiel PR be accepted?

[xinity]

@pothos @xinity Do you have a resolution for this? Would @jsalatiel PR be accepted?

well i'm not a sysext-bakery maintainer so my opinion worth almost nothing :)
if you ask me, sysext-bakery should be targeting complex setup and have a functional purpose, or else it will just end up as another packager manager, which i'm sure wasn't why it has been built for.

TLDR: before accepting or rejecting any PR , perhaps maintainers should think about guidelines, clear targets and expections.

Again i'm nobody to tell anyone what they should do, i'm just sharing my very personal point of view.
@pothos your thoughts ?

[chewi]

@pothos is away for an extended period. Unfortunately, I still don't know any more about this than I did in August. @tormath1, does this look okay to you?

[tormath1]

hello and sorry, I was totally unaware of the recent conversation here.

With this repository comes a natural question: what's the limit for proposed software? In this specific case:

There are several cases when the user needs to edit k8s yamls inplace directly on the master nodes and having syntax highlighting and advanced formatting of vim available is a nice feature since the default vim of flatcar have those disabled.

I think a good trade-off for Flatcar and this use-case would be to turn the default Flatcar vim to an official systemd-sysext (enabled or not by default, this can be decided later) and to compile vim without minimal feature.

1. Folks interested to have vim on Flatcar will enjoy the full experience
2. Folks not interested to have vim on Flatcar (and its regular amount of CVEs) will be able to remove it

As a reminder, Flatcar is designed to run containers and when containers can't fill the gaps (e.g kernel modules, alternative container runtime environment, etc.) sysext images can be used. This repository provides an easy way to extend Flatcar from its initial contract with software like Falco, ollama, wasm environment, etc.