how do we deal with version drift between sysext and the container image
how do we deal with version drift between sysext and the container image
Ado you remake it as part of the ujust and launch with a systemd service?
Aif you do that'd be very cool
N@Kyle Gospo is lacking in details. Such a tease.
KTBD, we can of course ship them as part of the image so they always match as a way to allow uninstallation of applications by deleting the extension
KBut stuff we aren't going to include by default is going to need some kind of store or updater
KOr, if built locally, will need a service to rebuild as needed
KIt's more or less a new package format
Aim convinced of sysupd and sysext as a packaging format
Ayet
Abut they solved a lot of problems already
NThat's the biggest concern I have. I wonder if maybe building a conversion tool that creates it from an RPM would be potentially a good way to go?
KGet outta my head
K:clueless:
NNo. I live there rent free with all the others.
Amy idea would be making a large oci image
NSquatter's rights.
Athen seperating the optional stuff that'd be sysext to the final layers
Aand generating manifests with certain layers missing dynamically
A@Kyle Gospo to celebrate the build today failing
Awe should include the kernel with the akmods
Aas part of the cache
TWHAT
Thow did you actually make it work
Toh my god
Tis that like the new sysrtemd version?
Tbrah we can already do the cool system extensions then
Tsadly that would still require doing patchelf prefixes
Afor me the problem is the packaging
Alike yeah i can call mount -t overlay myself i dont need systemd to do it
Ahow do i mage sure the user gets the correct extensions when updating
Nyeah, that's true.
Fi thought that akmods & kernel is tightened since latest tries
Awell wrong kernel got into the image
Fbut yeah, I get some build errors since 2 days ago cuz of akmods
Ajust put it in there dont think about it
Aand start slowly migrating to using the akmod kernel
Bthis is where the right tooling/packaging come in to play. when sysexts are built with the base OS image, it's just a matter of wiring things up.
Band now we're one step closer (tm)
Band then we're done
Aexactly
Abut we're doing oci, sysext is squash
Band that won't stop us from building them 
Awill stop you from hosting them lol
Bit doesn't have to be, your fs can come from anywhere including an OCI image
Eit's pretty straightforward to automatically build a squashfs artifact from an OCI image; or you could host a squashfs file in an OCI image
KYep, we'll just need some kind of distribution and update method. Both for package updates in the extensions, and for OS updates since you have to specify an OS version and ID they're designed for
Athats news to me
Athis is how i'd do it at least
Bman systemd-sysext/var/lib/extensions/. The first two listed directories are not suitable for carrying large binary images,
however are still useful for carrying symlinks to them. The primary place for installing system extensions is
/var/lib/extensions/. Any directories found in these search directories are considered directory based
extension images; any files with the .raw suffix are considered disk image based extension images. When
invoked in the initrd, the additional directory /.extra/sysext/ is included in the directories that are
searched for extension images. Note however, that by default a tighter image policy applies to images found
there, though, see below. This directory is populated by systemd-stub(7) with extension images found in the
system's EFI System Partition.
Jwe'd just build them regularly in github afaict? like how flatcar does it?
