we can do this, and we're marching slowly there
we 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.
Bahh
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.
Aim gonna be thinking about this
Nfrom a user experience perspective, I think the big thing is making whatever we do approachable.
Asolves every issue basically. Just need to lobotomize rpm-ostree to accept custom manifests
Eyeah, any dependency management/resolution would have to be implemented in the tool for downloading/managing local sysexts
Nwhether that be plugging it into a store or making our own tool to install it for them.
Athats what rpm-ostree does already though
Athats the whole point behind it, so you might as well use that
KGood addition to topgrade
Aif we are talking about rpms
Agenerates commits for the deployed packages and merges them to the original ostree commit
BBthat's a significant chunk of the process we're working on here. Even introduces the idea of delivering a sysext via flatpak. Maybe that's not for us... maybe it is.
Aarticle talks about GnomeOS
AGnomeOS uses sysupd
NI did not know about this.
Anot only that, but the systemd dude pushed for ostree to be replaced for it
AGnomeOS used ostree prior to that
Ai spilt the tea hon
A
NTopgrade is such a great tool.
TEndlessOS too
Tnot related sorry
Astill is
Aor did they switch too?
Ti think it's still OSTree
Jhwe skewed all sorts of ways today
Nskew seems to be an eternal problem lol
RClarifying what the ublue-os/cosmic repo is for, to try and prevent the feature requests flowing in.
Please leave your comments if anything can be made clearer.
https://github.com/ublue-os/cosmic/pull/67
Please leave your comments if anything can be made clearer.
https://github.com/ublue-os/cosmic/pull/67
