Cirrus: Use packaged-based dependencies

[cevich]

Building/installing dependencies from fixed source-version ensures
testing is reliable, but introduces a maintenance burden and
risks testing far outside of a real-world environment. The
sensible alternative is to install dependencies from distro-packaging
systems.

Install all development and testing dependencies at cache-image build
time, to help ensure testing remains stable. The existing cache-image
build workflow can be utilized at any future time to build/test
with updated packages.

[rh-atomic-bot]

☔ The latest upstream changes (presumably #1932) made this pull request unmergeable. Please resolve the merge conflicts.

[cevich]

N/B: Images built from this PR here: https://cirrus-ci.com/task/6236613032017920

[cevich]

Status (Both Fedora 29 and Ubuntu 18.04)

• The package-based mechanics are working (though may be missing some pieces).
• Direct podman testing dependencies are installed/upgraded at cache-image build-time.
• At PR test-time, they are installed/upgraded again (to handle differences from, or benefit from cache).
• All files associated with the 'podman' package are removed (to prepare building/installing from source).

@baude @mheon need some discussion/guidance here, given the frequent "issues" we've hit in PR & Master testing WRT runc (or any other direct dependency really). I'm afraid this approach is going to shackle modern libpod development work, to potentially much older dependency (e.g. runc) API's, behaviors, and bugs. At the same time, for any expected incompatible feature/API gaps, specific tests will need to be automatically skipped based on the dependency versions. That often leads to incomplete code coverage at the "edges" of tests.

In other words, if a runc problem is found by CI in a libpod PR, the author may potentially wait a long time (days) for an upstream fix, test, review, merge, test, package, and more testing.

Or (maybe worse), a test which touches a new (not yet available in runc package) feature and other code may be skipped. Meaning the "other" code does not get tested at all.

Are these things actual problems, and something we want to stand in front of as a libpod PR merge requirement? Tell me your thoughts?

BTW: I'm open to having two sets of tests, one being package-based, the other running with test-time compiled, "latest-master" version of the direct-dependencies (no sha-binding like before). If this is a better idea, which (or both) should be a gate for PR merges vs just advisory testing?

[cevich]

note to me: Ubuntu fails b/c searching for conmon in deprecated locations. Need something like #3429 to fix.

[cevich]

@rhatdan @mheon @baude Finally after months and months of toil, I think this is ready. PTAL.

[mheon]

This is smaller than I thought it would be. A lot easier to review as such.

Initial pass, everything seems reasonable. I'd just like @baude to have a look at the Varlink stuff - I know that's a packaging minefield.

[cevich]

This is smaller than I thought it would be.

Much of what made this PR so large originally, was split off into XXXL #2561 (already merged) 😄 Having that was absolutely critical for finishing development on this PR. Also critical was all of @haircommander and @lsm5 efforts on splitting/packaging conmon and maintaining the other dependent packages (thanks!).

[cevich]

@mheon @baude anything else holding this one back?

[mheon]

LGTM on my end
@baude @rhatdan @giuseppe PTAL

[rhatdan]

/lgtm