Are you going to cover "podman-remote" and varlink anything, or is that out of scope given the Fedora focus ?

Although Fedora might possibly be the only place that the resolver is available, or at least where it used to be...

https://copr.fedorainfracloud.org/coprs/g/varlink/varlink/packages/

Starting to think that it might be easier to just use "ssh sudo podman" ?

/Anders

Den 2019-08-18 kl. 23:29, skrev Robert P. J. Day:

On Sat, 17 Aug 2019, Daniel Walsh wrote:

Just off the top of my head:

o    What are Containers

o    The container applications

o    Quick intro to Buildah

o    Deeper intro to Podman (Podman uses Buildah when it does `podman
build`).

... snip ...

  i'm going to follow up on my earlier post with a thought that might
provoke a reaction but, what the heck ... (i'm free associating here
so, be warned ...)

  i've designed and delivered a *bunch* of linux/linux-related
courses, and one of the things that seems to really, really, really
set the stage properly early on is to list the components to be
covered, and map those components *specifically* to the red hat/fedora
packages that provide them.

  it may sound weird but, in the relevant courses, students seem to
grasp the "big picture" more quickly if one not only lists the
concepts to be covered, but maps that to actual fedora (my OS of
choice) packages, along with what each package provides. let me give
an example.

  if i'm going to teach a course on containers on fedora (which is my
plan), it would be easy to just:

  $ sudo dnf group install --with-optional "container management"

and go from there. but my experience is that it's clearer if one
starts with the *minimal* set of packages to get started and, as the
class progresses, one by one, installs each additional package only
when necessary, while explaining what that new package brings to the
table.

  so, after displaying the various components of container technology,
i would start with only podman (and, sure, podman-docker) installed,
and cover what that allows one to do.

  once that's done, introduce and install "buildah", and work with
that. after that, skopeo, i guess, and so on, and so on. mapping each
feature to a separate package really drives home the idea that these
are different features that can be installed and worked with
separately.

  over the next day or two, i'm going to flesh this out and put it all
on a wiki page to make it clearer. i guess what i'm talking about here
is explaining the entire container "ecosystem", and mapping that to
the (fedora/RH) packages that support it.

  thoughts?

rday