apt2ostree VS ostree

Hm yes now I remember that point about how the data is anonymous Python objects that you can pass around to functions.

Are there any open source examples? I looked around the github account, but I mostly remember this tool

https://github.com/stb-tester/apt2ostree

I'd be interested in seeing the Python config and Ninja output, to see how it works. Right now it looks to me like the dependencies are more implicit than explicit, e.g. with your copen example

---

The system I ended up with is more like Bazel, but it's not building containers, so it's a slightly different problem. But I'm interested in building containers incrementally without 'docker build'.

I like the apt lockfile idea definitely ... However I also have a bunch of other blobs and tarballs, that I might not want to check into git. I guess you just put those in OSTree?

Our config looks like this

https://github.com/oilshell/oil/blob/master/core/NINJA_subgr...

And all the code is in build/ninja* of the same repo

However, you can get pretty close yourself with a tool like this https://github.com/stb-tester/apt2ostree

With apt2ostree[1] we use lockfiles to allow us to version control the exact versions that were used to build a container. This makes updating the versions explicit and controlled, and building the containers functionally reproducible - albeit not byte-for-byte reproducible.

[1]: https://github.com/stb-tester/apt2ostree#lockfiles

On the subject of reproducible debian-based environments I wrote apt2ostree[1]. It applies the cargo/npm lockfile idea to debian rootfs images. From a list of packages we perform dependency resolution and generate a "lockfile" that contains the complete list of all packages, their versions and their SHAs. You can commit this lockfile to git.

You can then install Debian or Ubuntu into a chroot just based on this lockfile and end up with a functionally reproducible result. It won't be completely byte identical as your SSH keys, machine-id, etc. will be different between installations, but you'll always end up with the same packages and package versions installed for a given lockfile.

This has saved us on a few occasions where an apt upgrade had broken the workflow of some of our customers. We could see exactly which package versions changed in git history and roll-back the problematic package before working on fixing it properly. This is vastly better than the traditional `RUN apt-get install -y blah blah` you see in `Dockerfile`s.

IMO it's also more convenient than debootstrap as you don't need to worry about gpg keys, etc. when building the image. Dependency resolution and gpg key stuff is done at lockfile generation time, so the installation process can be much simpler. In theory it could be made such that only dpkg is required to do the install, rather than the whole of apt, but that's by-the-by.

apt2ostree itself is probably not interesting to most people as it depends on ostree and ninja but I think the lockfile concept as applied to debian repos could be of much broader interest.

[1]: https://github.com/stb-tester/apt2ostree#lockfiles

[2]: https://ostreedev.github.io/ostree/

https://github.com/ostreedev/ostree

My impression from the splash page is you're more encouraged to install packages to the base system. Silverblue only has that as the last resort (after flatpak, toolbox and podman).

Flatpak essentially decouples OS level packages from (GUI) App packages, and this is radically different to "unix way" and some people freak out of it. Flatpak is primarily meant for "apps" (those having GUI and used by users), not for "services", "libraries" and alike things. I love flatpak because: - I (as a user) have no time to keep eye on every app on my system, update and build it from source each time it updates/releases (I have family and work to do, no time for this). - developers (of apps) have no time to adapt their dependency libraries to match every linux distro out there (this usually causes that some GUI app cannot be built, or is very painful to build on some given distro). - distro developers have no time to adapt every included app library dependencies to match their own distro library versions (this usually causes that distros "freeze" their own shipped GUI apps to some, usually "ancient" version). - disk is cheap. So, flatpak is for rescue: - is ideal for GUI Apps, is not meant to replace system packager (like rpm, apt, etc). Think "libreoffice" and alike apps. - it uses libostree (one can say "git for binaries") https://ostreedev.github.io/ostree/ - apps are (ideally) packaged alone (no libraries included, unlike AppImage for example) but with declared dependencies, and dependencies are downloaded automatically by flatpak - this means there is no duplication (in case app A and B both use some "lib", that lib is downloaded only once and is shared) - this also means there IS "duplication" in case installed app requires different plaf or library versions (in case app A wants lib 1.0 and app B wants lib 1.1, both lib 1.0 and lib 1.1 will be downloaded). Once dependency is gone (as app A updates to lib 1.1), the lib 1.0 is purged as well (removed from your disk). Personally (while on Linux Mint) I tried to: - install base OS and Cinnamon DE from distro provided packages and reposes (deb packages) - keep OS package tree as clean as possible (so no custom reposes, no PPAs etc) - install all GUI Apps from flatpaks (and Linux Mint udpdate manager kept them up to date) Sadly, Linux Mint flatpak support was lagging way too much from mainstream. Since on Fedora 36, this almost happens automagically.

It uses Faltpak for apps and rpm-ostree for the system, based on libostree.

They do though, flatpaks use ostree for immutability of their binaries.

Because they're established terms, and the witchhunt goes so far as to break builds and cause needless work just for the sake of political correctness: https://github.com/ostreedev/ostree/issues/2360

Political correctness linters require you to explicitly acknowledge or disable warnings when you're doing things like pasting existing URLs.

And it never stops with one term. It started with master/slave (which are now replaced with dozens of synonyms that are often hard to figure out), then whitelist/blacklist, and the activists are already queueing up the next words for sure.

Few people want to ban others from using alternative terms that they consider better, but where they draw the line is when others prevent them from using the terms they deem appropriate, or demand/force additional work.

But if you want to you can, under the hood silverblue uses https://ostreedev.github.io/ostree/

On the subject of reproducible debian-based environments I wrote apt2ostree[1]. It applies the cargo/npm lockfile idea to debian rootfs images. From a list of packages we perform dependency resolution and generate a "lockfile" that contains the complete list of all packages, their versions and their SHAs. You can commit this lockfile to git.

You can then install Debian or Ubuntu into a chroot just based on this lockfile and end up with a functionally reproducible result. It won't be completely byte identical as your SSH keys, machine-id, etc. will be different between installations, but you'll always end up with the same packages and package versions installed for a given lockfile.

This has saved us on a few occasions where an apt upgrade had broken the workflow of some of our customers. We could see exactly which package versions changed in git history and roll-back the problematic package before working on fixing it properly. This is vastly better than the traditional `RUN apt-get install -y blah blah` you see in `Dockerfile`s.

IMO it's also more convenient than debootstrap as you don't need to worry about gpg keys, etc. when building the image. Dependency resolution and gpg key stuff is done at lockfile generation time, so the installation process can be much simpler. In theory it could be made such that only dpkg is required to do the install, rather than the whole of apt, but that's by-the-by.

apt2ostree itself is probably not interesting to most people as it depends on ostree and ninja but I think the lockfile concept as applied to debian repos could be of much broader interest.

[1]: https://github.com/stb-tester/apt2ostree#lockfiles

[2]: https://ostreedev.github.io/ostree/