On Wed, Feb 7, 2018, at 1:58 PM, Dusty Mabe wrote: > > Oh, great! for some reason I assumed rpm-ostree can only download > > pre-composed trees from Fedora.
Right, rpm-ostree is a fully hybrid system, it links to libdnf *and* libostree and combines functionality from both. See: https://fedorapeople.org/~walters/2018.01-devconf/index.html#/3 > > In the future it might be worth to add some sort of compatibility wrapper > > around "dnf install" (and such) like dnf has for yum - to show a message to > > let you know that tool is "deprecated" and that rpm-ostree is what they > > need to use now. Otherwise people might get confused about "how do I > > install anything? non of the tools I'm used to are here". But `dnf` isn't deprecated! As a *developer* I spend the vast majority of my time in my dev containers using yum/dnf. It works well there! You need to get used to thinking in terms of "host" vs "container/disposable VM/etc". The rpm-ostree package layering is something you will generally need to understand a lot upfront, but after that it fades into the background, and that's the idea. Though a cool aspect IMO of all of this is that if you aren't doing development, the "pure desktop" case of OS + web browser can be pure "ostree" mode, no client side dependency resolution at all. > > At the moment, I can have auto-updates for my host system and for my > > Flatpaks, but there's no real mechanism to update containers. I assume > > people will not be happy if we just automatically run "dnf update" inside > > all their containers, but if you have a lot of "contexts" you'll have to > > update all of them yourself. I have definitely spent a lot of time thinking about this too. Actually, the rpm-ostree tooling is fairly easily generalizable to generate and maintain an *arbitrary* set of root filesystems, updated from RPM packages. But here's the thing - I also need to build/test some software on e.g. Debian. If we build out a lot of RPM-specific tooling for containers, it doesn't help that case. Further what people tend to do in containers is things like `sudo pip install` or equivalent. I actually do that myself sometimes transiently for e.g. `sudo pip install python-openstackclient`. Generalizing "check for updates" to that is extraordinarily hard. Anyways, you're right this is a big problem space; there's not going to be one magical solution. I personally have found the tradeoffs to be worth it. And I think we'll iterate towards a more opinionated tool here that at least handles the default case of containers built from RPMs + layer of config or so; perhaps maybe even eventually hooking up gnome-software to understand how to do updates there too. Personally right now I use a mix of `yum update` periodically and just rebuild from scratch every few weeks.
