Re: [atomic-devel] Fedora Atomic Workstation questions

On Wed, Feb 7, 2018 at 10:02 PM, Colin Walters <walters verbum org> wrote:

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.

I know it's not deprecated, that's why I used quote marks.

I think that when you try to run dnf from a host context (not inside a container) you should get a message explaining that you're running on the host, where you should use rpm-ostree instead (as opposed to just an unhelpful "command not found" message)

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.

Yeah, it's cool, but Fedora Workstation's main target audience is still developers, who do have to develop stuff eventually.

> > 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.

It's theoretically possible to use packagekit to cover the "different distributions" case, but I don't think it's it's a good idea.

I think it makes sense from a user's perspective to understand that a "managed container" / "context" (if such thing will ever exist) can only be based on the host.

So it's like "host+extra stuff I need for development". For the usecase of developing/testing on another distro, you'd use a "normal" container that you wouldn't expect to be managed.

The tooling to create/run the so called "managed containers" can be different than the usual container tooling, so the distinction will be clear and the user will know what to expect.

As for pip (and other related language specific package managers) - people don't usually update these unless they require the newer version.
This is not great from a security perspective, but I think it's a bit out-of-scope for this discussion. It's not plausible to support all of these systems. I also think no developer would appreciate their dev env breaking "randomly" when something from pip updates in a way that breaks API. Fedora does (attempt to) guarantee API/ABI stability on regular updates, so they're "safer" to apply automatically than say something from "pip" or "gem".

-Elad.