I added "go" to a sysext and mounted it

I expected the "go" binary to be available after refreshing, but it wasn't because go is installed in /usr/share/go/bin and I don't think bext knows what to do about that

We gotta implement some kind of build cache for this project, because re-fetching everything for every image build is not particularly efficient.

We can do that by using one of these approaches:

• Nix Magic Cache by Determinate Systems
• Layered Nix Stores (mounting these things require root, so maybe not)
• Chroot Nix Stores

title

That will make Bext be able to support a lot of ways of building new images!

Stuff like a "script" plugin will allow people to use scripts for building those.

A homebrew plugin, whatever else, really

Its mostly just a usability issue, like mounting requires you to mount each part separately, running bext mount extensions, then bext mount store, then bext mount path. It would be pretty sweet to include a command like bext mount all to mount everything at once.

change add-to-path logic to add /tmp/extensions.d/**/bin
change bext to add extension name in /tmp/extensions.d/NAME/bin

This limits the amount of layers that a user can have. Maybe having another filesystem to do that work, or using symlinks somehow, could help circumvent this issue

This may help out as linting and making sure the code actually runs before commiting is very helpful :)

add goreleaser

We could add a tag for user-only operations, requiring only FUSE support to work. Cache directories can be rewired to be on specific user paths, so that is not an issue, but the mounting requires rootful access, because we use syscall.Mount, and syscall.Unmount to make it work, but we can require the target machite to have fuse-overlayfs and maybe bindfs to completely make the mounting rootless

Since systemd-sysext is just glorified overlayfs, we could not depend on it by using overlayFS to mount everything up on the target system (the best idea would be to have a tag for enabling/disabling systemd-sysext). This would increase compatibility to quite literally any system that has OverlayFS support, even stuff like the BSD family could have support for this

add systemd one-shot to create /nix/store
make it run before bext-mount

Portability could be increased in this project in both of these cases:

Runtime

We could, instead of mounting /usr/store onto /nix/store, which requires root (currently, see #17), use nix-user-chroot or bubblewrap to wrap all the /usr/extension.d/$EXTENSION/bin symlinks to them and include /usr/store as /nix, making it think /nix/store exists when it doesnt, that would also remove the requirement for root for mounting /nix

Building

We could also build stuff with nix-portable or nix-user-chroot instead of spinning up a docker/podman container so that people may use bext layer build inside a distrobox or something like that

Since projects like oci-sysext exist, having layer build and layer init split into a command like bext nix init bext nix build would be better for organization, considering that the #27 is meant to add support to other styles of sysexts, like oci-sysext generated ones.

This project contains both Bext and BextStatic packages, would be awesome to have them in FlakeHub

create github action to build recipes with bext

add signature to binaries with ublue's cosign key

We could do something like we already do with signed containers with [cosign] but with our images! Even if that means just making a tarball with the image inside, it would be great to have proper signing. That would also require BEXT to support that signing and check if it is valid through some program like bext sign or something like that

This is a clone of #6 but worded in a different way, I literally didnt see this issue before, sorry

Might want to write some explanations in the README about what the intention and purpose of this repo is to attract more collaborators.

👍

Would be sweet since YAML is so easy to edit. Shouldnt be too much of a hassle to implement either, since the "YAMLtoJSON" function exists in the pkg/ directory

A command for checking if a provided system extension is valid, and explaining why it isn't if not.

The user would do something like

bext layer check [FILE]

And the command would open up the layer and check out what is right or wrong, like LAYER/usr/lib/extensions.d/LAYER.sysext has the same name as the target layer, or if there is a LAYER/etc directory, for example.

Well, would be sweet to have stuff like CODEOWNERS, ISSUE_TEMPLATE, and everything else :>

Would be awesome to have something like < $(bext layer init) bext layer build actually work. May help out a lot with scripting with BEXT

Using threading / Concurrency for editing cache content will massively speed up big cache stores