Having a traceable system that is not immutable + image-based?

Project Discussion
,
1

I was recently wondering… for me the benefits of an immutable system are

  • control over every package
  • resetting possible
  • deviation from main OS is always visible

Could’t this also just be done like that? Keep track of every file change in the currently read-only directories, list these files, list overwrites or removals…

And if you want to perform these actions, show the exact deviations from the system, delete them and replace exactly these files with the official repos ones…

You dont need to build a seperate image, if you know exactly how your system and the other system differ from each other?

I imagine somthing like git for the entire system? At least excluding the ~/var and the symlinked repos, so they are ignored?

Is that technically possible? I think its so inefficient to do Fedora Kinoite updates, as every stupid little package is copied and packed into a new image, regardless of the fact it was changed or not.

It could still be possible to create a BTRFS snapshot of your image, before for example switching Desktops or doing an upgrade. But the rest?

I think just versioning and tracing every system file in the background would make way more sense than an immutable system, at least for rolling systems.

I can imagine if you update every 2 weeks or so, not having that tracing in the background suck resources may be better than investing the image building time.

2

I imagine somthing like git for the entire system?

You’ve just described OSTree.

I think its so inefficient to do Fedora Kinoite updates, as every stupid little package is copied and packed into a new image, regardless of the fact it was changed or not.

Updates don’t download the entire new image, just files that have changed in the new commit, or even a “static delta” containing the changes in those files.

2 Likes
3

Okay nice, so OSTree is what I imagine.

I know that only the different packages are downloaded, but the entire image is created, which takes up to 5min and requires loots of CPU power compared to regular usage. So every package is copied locally

1 Like
4

Images are built on CI, not on user machines. All the user is doing is pulling them.

5

Huh?

The user has a traced OS image. Rpm-ostree checks for changes on the repo. Downloads the diff. And builds the updated image locally.

So this means that the complete image is duplicated and built locally, or not?

Maybe you understand what my goal here would be. A fully traced system that is not immutable.

  • you want to install a random package? Do it, will be marked as “difference from repo image”
  • you want to self-compile some software? No problem, will just be ignored, a reset will remove it, or reinstall the regular kernel if it was a kernel mod for example
  • you want to change currently immutable system dir files? No problem, will be traced and can just be removed or reset, if the files or their contents dont match the repo

You would basically have the exact same, just that the building of the complete image would only be done when necessary, when you broke your system and actually need a clean new image.

The only thing I wonder is how atomic updates would work.

6

I’m not considering your proposal, I’m clarifying what ostree already does.