If I'm on Fedora 40 and upgrade to 41, my existing extensions are now invalidated unless they also u
If I'm on Fedora 40 and upgrade to 41, my existing extensions are now invalidated unless they also update
Bthat's the tooling and pipeline we need to build
Jright, we'll need to version for F41, etc.
KWe also don't want to ship extensions that may or may not have security implications without a way to update those extensions
Aid hope for fedora 41
Abut the problem is day to day
Ayou also need to update it
Aas far as i understand it
Aie 240420 image has different extensions than 240424
Athey have to be pinned to the exact image
Jall the docs I've read point to the extension living in /var/lib/extensions
Bthere is a new download service in systemd 256 we can use
NIs there a way to build tooling to utilize other existing tooling? Or is there no way to achieve that? What I hope to see avoided is yet ANOTHER way to package linux packages.
Jand a service just updates a new one in place
Afrom everything i read, sysext is the brother to sysupd and they are designed for each other
Awe're in the bootc camp, theres some conflict with that
Ecould we provide a similar maintenance/usage pattern for updating sysexts as what was described in the video introducing logically bound images to bootc?
Asysupd also uses squashfs images
Jwhy is there conflict?
Aessentially the design of sysext is get your image with sysupd which is squashfs
Athen apply the sysexts which are also squashfs
NAthe systems are designed for each other
Ae.g, you'd host both on an HTTP host
Awhen using with ostree oci you get conflicting delivery methods for the base image and the extensions
Aand conflicting versioning
Bwe can use sysupdate to download our extensions: https://github.com/flatcar/sysext-bakery see the bottom "consuming"
GitHub
Recipes for baking systemd-sysext images. Contribute to flatcar/sysext-bakery development by creating an account on GitHub.
Jyeah I don't get why people think we can't snag and update these things, the bakery has been doing it since day 1
Bwe can do this, and we're marching slowly there
Awe'll get there
Aone important part of the puzzle was getting rechunk to work so that updates are manageable
Anow, slowly but surely extensions
NI guess what I mean is what @Kyle Gospo and I talked about earlier which is trying to use already existing packages and then converting them into system extensions transparently.
Athats also a possibility
NLike, I don't need to create a custom formatted thing to work as a system extension, I already have an RPM package with all the information I need to get it installed on a Fedora system.
Aand a good idea
NThen you don't need folks to repackage everything AGAIN 
Ahave a postprocessing hook that runs after rpmostree update and recreates the extensions in a parallel dir that matches the deployment
Aactually, probably a single extension
Athen does some selinux labelling
Nfor sure. the other cool thing is if you had a tool like this, you could get it working for DEB packages as well.
NRPM and DEB would be your 2 big ones you would want.
Aif i think about it the only problem with it is dependency management
NDoes Flatpaks serve a use case here or could you theoretically get rid of them now that you have systems extensions?
Aof course they do
Aif it can be a flatpak it should be
Abut since we're doing OCI
Esystem extensions don't do any sandboxing; the use-case is more for system files/programs
NThat's a good point.
NI was more thinking about how people complain about RPMs vs Flatpaks.
