Re: [atomic-devel] Fedora Atomic Workstation questions

[Colin Walters <walters verbum org>]

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.