IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Now that we have the ability to both track clients and our active transaction,
and the `RegisterClient` call acts "atomically", let's start doing exit-on-idle
and return the RAM to the people.
Closes: #606
Approved by: jlebon
Was just reading the initramfs bits while talking to rubao about kargs work, and
noticed we had a lot of "old style" declarations.
Closes: #1020
Approved by: jlebon
Amazingly we had 3 variations of this bug in the different
layers above using the `RpmOstreeContext` API (in compose, container,
and layering).
We fixed the first two already, this fixes the last one. We
get a warning if librpm holds a ref to a deleted rpmdb.
Closes: https://github.com/projectatomic/rpm-ostree/issues/987Closes: #994
Approved by: jlebon
Also something I noticed while working on #981. When sitting on a livefs
commit, once a user does `rpm-ostree cleanup --pending --rollback`, it's
impossible to redeploy the same booted commit. Let's allow users to do
this.
Closes: #984
Approved by: cgwalters
Currently, when setting the `override-commit` key in the origin, the
upgrader pulls that commit checksum directly and then updates the
refspec to point to it. This behaviour was inherited from its ostree
version; at the time it was implemented, the pull code didn't support
passing a specific commit for a given refspec. However, we now have
the override-commit-ids option, which will make libostree update the ref
for us.
We change the code here to make use of it and simplify the function.
This also fixes the corner case of local branches: we shouldn't change
the ref if we're on a local branch. This is actually what drove me to
this patch as I was debugging #981.
(Aside: I'm still not convinced updating the refspec is always the
correct thing to do even in the remote case, though it's a bit messy to
disentangle).
Closes: #984
Approved by: cgwalters
Prep for changing `boot_location: new` to use `/usr/lib/ostree-boot`
and `/usr/lib/modules`. Rework our kernel postprocessing
so that we unify the `boot_location` handling with initramfs generation.
Instead of doing the initramfs first in postprocessing, we do it nearly last,
after e.g. `etc` is renamed to `usr/etc`. This has some consequences, such as
the fact that `run_bwrap_mutably()` is now called in both situations. In
general, our handling of `etc` is inconsistent, although understandably so.
As part of this, I finally got around to implementing the bit from
https://github.com/systemd/systemd/pull/4174 however suboptimal it is; need the
unified core so we can cleanly ignore the posttrans like we do others. We
intentionally keep the file around in the generated tree so that installing a
kernel RPM per client doesn't try to do any of this either.
This all gets folded together so that the logic for handling the bootloader gets
simpler - in the Fedora case, we now know to find kernels in `/usr/lib/modules`
and can ignore `/boot`.
Closes: #959
Approved by: jlebon
This fixes `rpm-ostree reload` as root, and supports configuring
it to be enabled for other users as well. This was overlooked
in the polkit work originally.
Closes: https://github.com/projectatomic/rpm-ostree/issues/976Closes: #977
Approved by: jlebon
The core use case always enabled this; we exposed it on the command line, but
honestly I think it's a lot simpler if our imports always enable this. If we
need to *undo* it (for example, generating a "traditional feeling" OCI/Docker
image a la <https://github.com/projectatomic/rpm-ostree/pull/367>), we can
easily do that as postprocessing afterwards.
Closes: #951
Approved by: jlebon
It was partially removed in 325ee354e9
from PR #873 - this removes all of the rest of the layers in
the daemon and core for this.
Note that while working on this I found it astoundingly confusing that
`rpmts_add_install()` and `add_install()` had separate orderings for `gboolean
noscripts, is_install`. That's fixed by having the latter lose the `noscripts`
flag entirely, but while we're here change `rpmts_add_install()` to use flags
for clarity.
Closes: #938
Approved by: jlebon
Lots of cleanups, and this also allows us to fully port to new style in several
places.
We can drop our own `rpmostree_mkdtemp()`.
Update submodule: libglnx
Closes: #928
Approved by: jlebon
Since we have a copy of this libostree code, pick up the new
changes from <https://github.com/ostreedev/ostree/pull/1055>.
Note the added test doesn't really test our logic since
we're only doing local pulls, but at least we have something.
Closes: #932
Approved by: jlebon
Make use of the new journal-msg signal that OstreeSysroot emits. Since
we now also only rely on the output API to print messages, this allows
us to drop the outrageous hacks we had to do to watch our own stdout,
part of which Coverity didn't like.
Coverity CID: 163694
Closes: #919
Approved by: cgwalters
There were places where we were relying on the stdout self read hack to
relay messages to clients. Fix those by explicitly using the output API
in all spots where the daemon may pass. Really, we should exclusively be
using the output API in the daemon and libpriv trees, though many other
instances exist for now.
Closes: #919
Approved by: cgwalters
This closes a longstanding bug - since package layering first
landed, we only checked for newer RPMs if the base tree changed.
In some scenarios like RHELAH, this doesn't matter much by default
since they move at the same cadence. Except if you use EPEL for example.
In Fedora, today the FAH releases are async of the rpm-md repos, and
there's also COPR which can update more than once a day even.
We should check for both update sources. Luckily we'd already introduced logic
for this in the treecompose case (checksumming the depsolved package sack). We
just need to start using it for client side assembly too.
Closes: https://github.com/projectatomic/rpm-ostree/issues/391Closes: #911
Approved by: jlebon
This is no longer necessary since we switched to tracking livefs state in the
origin, and we don't support changing content outside of `/usr` right now
via livefs.
Just noticed this while looking at the livefs code.
Closes: #912
Approved by: jlebon
The new API to find pending and rollback deployments do so relative to
the booted deployment. This caused an interesting behaviour: the first
time a user uses "rpm-ostree rollback", it would (as expected) move the
previous deployment first. but the second call to "rpm-ostree rollback"
would fail since there were now no more rollback deployments.
We fine tune the logic here to allow this, as well as the more general
case of putting the booted deployment back on top.
This fixes a subtle regression from b7cf58e
(https://github.com/projectatomic/rpm-ostree/pull/767).
Closes: https://github.com/projectatomic/rpm-ostree/issues/906Closes: #907
Approved by: cgwalters
Now that the query_deployment() function was upstreamed in ostree (see
https://github.com/ostreedev/ostree/pull/897), let's just use it from
there and drop our copy here.
Closes: #907
Approved by: cgwalters
When commit metadata contains ostree.endoflife attribute,
its information will be added to the deployment Variant,
which will later be shown as a red & bold message when
'rpm-ostree status' command is called.
A test is added for future regression
Closes: #889
Approved by: cgwalters
This is a followup to https://github.com/projectatomic/rpm-ostree/pull/888
but more comprehensive; in the layering case, the sanitycheck runs
after all the `%posttrans` scripts, so we'll get a consistent error message
for the `rm -rf /` test.
We also do the sanitycheck for the "pure ostree" case, as well as cases
where we didn't actually layer packages (including `ex override remove` as
well as simply regenerating an initrd).
There's obviously a lot more we could do in a sanitycheck; as I say in the
comment it's tempting to consider trying to boot systemd (in a fully volatile
config), but for now let's do this. In the end of course the admin has rollback
too.
Closes: #892
Approved by: jlebon
Drop the root check for RegisterClient() so that any UID can use it to
then safely invoke methods. UIDs which already have an active session do
not need to authenticate for RegisterClient().
In order to implement this, we move the polkit authority setup into the
RpmostreedSysroot object and enable polkit on the interface.
Closes: #894
Approved by: cgwalters
Closes: https://github.com/projectatomic/rpm-ostree/issues/546
Previously, we'd open up the host's rpmdb for both `compose tree`
and `ex container`. In the first case, because we require root, we'd
succeed. For `ex container`, we'd spew an error.
Fixing this was trickier than I thought. First because there was
*also* a libdnf bug here: https://github.com/rpm-software-management/libdnf/pull/307
Second, there's a compatibility hazard here for anyone using `.repo` files that
reference `$releasever`. This actually happened to me with `ex container` as I'd
just done a `ln -s /etc/yum.repos.d/fedora.repo rpmmd.repos.d`. I fixed
that first by doing a `sed -i -e 's,$releasever,26,' rpmmd.repos.d/*.repo`.
As far as I can see today, none of Fedora Atomic or CentOS AH rely on this. But
in order to enhance compatibility, let's add a "releasever" option. This makes
it easier again to reuse stock `.repo` files if we wanted to do so.
(Also, I realized we can just use `/usr/share/empty` as *the* canonical immutable
empty directory)
Closes: #875
Approved by: jlebon
Add experimental support for replacing packages from the base layer with
local RPMs. This is useful for example, to cherry pick a fixed package,
or to roll back to a previous package version. Like with pkg removals,
only files in /usr are actually replaced.
This patch also contains a few usability improvements as well, e.g.
showing the full NEVRA of removed packages rather than just their names,
and support for resetting overrides using either the pkgname or NEVRA.
Closes: #852
Approved by: cgwalters
This function was already mostly in the new style. Just moving the
declarations closer to where they are used. No functional changes. The
logic will be tweaked in an upcoming commit.
Closes: #859
Approved by: cgwalters
I initially planned to use the metadata tmp dir for another reason than
just in finalize_overlays(), but I will not anymore. Regardless, this
seems like a nice patch which also allows us to complete the style
conversion in this file.
Closes: #847
Approved by: cgwalters
This is an extension to the previous change to distingush between
"caller" and "client". Now for clients we log the uid (both
in the message and structured).
This is a natural followon from the polkit work, since now different
uids can invoke us.
Closes: #838
Approved by: jlebon
A "caller" is a bus address that hasn't called `RegisterClient`.
Prep for things like unifying the bus name tracking between the transaction and
the daemon; right now it's a bit silly that the txn code also monitors the
caller's bus name. So down the line we could change that code to call into the
daemon and use its tracking for registered clients.
Closes: #837
Approved by: jlebon
The property of removal overrides dropping out if the package was
removed from the base layer felt a bit too magical and hacky. We really
should remember that wish and re-apply it if the pkg comes back. This is
similar to package layering: requests can become inactive (seems like a
better word than "dormant") if the package is already part of the base
layer, but they don't really go away.
This patch reworks the logic so that removal overrides work the same
way. In the status output, we now have both "RemovedBasePackages" and
"InactiveBaseRemovals" (which is only printed in verbose mode),
similarly to how we have "LayeredPackages" and "InactiveRequests". And
similarly, we also print out in the upgrader during a transaction all
the inactive base removals.
Another cool thing is that we now allow any pattern to be specified at
the CLI. E.g. `ex override remove /usr/bin/strace` will resolve to
strace.
Closes: #836
Approved by: cgwalters
In the JSON output, the "requested-packages" holds *all* the requests
for package layering, whereas the "packages" key holds only those
requests which actually caused a package to be layered.
When outputting RequestedPackages, we try to be nice and print only the
"dormant" packages, i.e. those requests which did not require any
packages to be layered since the base layer already fulfilled them. This
is the subset of "requested-packages" not also in "packages". But then,
we could call this subset something much more appropriate than
"RequestedPackages" when outputting.
This patch renames it to "InactiveRequests" to reflect the "dormant"
aspect of them. We also make it only be output in verbose mode, since
it's not as interesting as what was *actually* layered when trying to
understand what the host is currently running. But we do adapt the
upgrader so that it prints out inactive requests during transactions.
Closes: #836
Approved by: cgwalters
Example of what the new macros look like when applied on a whole
codebase. It definitely feels much nicer to work with!
Update submodule: libglnx
Requires: https://github.com/GNOME/libglnx/pull/55Closes: #834
Approved by: cgwalters
This allows non-root users access to the rpm-ostree daemon, which is
a pre-requirement for gnome-software rpm-ostree support.
Closes: #745Closes: #825
Approved by: cgwalters
This is just a cosmetic patch that ensures we use the same names for the
same things everywhere to make it easier to follow along.
Closes: #829
Approved by: cgwalters
Only add information to it re. installing/uninstall/local installs after
we check that the corresponding arrays are not `NULL`.
Closes: #826Closes: #827
Approved by: cgwalters
This is part of the saga of permissions and checkouts that
came about thinking about flatpak, but suid and world-writable dirs
are also an issue for us.
There's no reason to make suid binaries accessible temporarily
to users while we're computing a new root. Similarly, we don't
want anyone to actually *write* to our temporary `/tmp`. The
simple fix is to make an intermediate dir that's `0700`.
See: https://github.com/ostreedev/ostree/pull/909
See: https://github.com/flatpak/flatpak/pull/843Closes: #821
Approved by: jlebon
This is one more step towards making rpm-ostree more powerful in its
quest to be the ultimate *hybrid* image/package system. Package layering
allows us to add packages on top of the base package set received from
the content provider. However, we're not able to remove or replace
packages in the base set itself.
This patch introduces a new `override` command, which is for now nested
under the experimental `ex` command. The `override` command will allow
users to modify the base package set itself. The first implemented
subcommands are `remove` and `reset`.
A stub has been provided for the more useful `replace` subcommand,
though much of the needed logic for that operation are implemented in
this patch as part of the `remove` subcommand.
Part of: https://github.com/projectatomic/rpm-ostree/issues/485Closes: #797
Approved by: cgwalters
1. There's no point in passing a GCancellable in those cases. All the
manipulations should be short-lived.
2. Rename delete_packages to remove_packages, since "remove" is the
proper antonym of "add".
Closes: #819
Approved by: cgwalters
There's a lot that could be done to improve this; we're not setting a title for
`rollback` etc. But I think in practice right now the "deploy" path (which
includes upgrade/install) etc. is most important.
Re-synthesizing a human readable string here is definitely a bit fragile and
going to be a maintenance pain. One thing I debated is having the client send
its commandline as a string. But that would only work for `/usr/bin/rpm-ostree`,
not e.g. Cockpit.
Anyways for now, this is useful and we can always improve it later.
Closes: https://github.com/projectatomic/rpm-ostree/issues/454Closes: #814
Approved by: jlebon
There's a subtle but classic issue in this code: calling `continue`
really just continued the inner loop, whereas we meant continuing the
outer loop.
Fix this by making the prefix lookup check a proper predicate function.
Place that function somewhere public, because we'll make use of it in
base overrides as well.
Closes: #807
Approved by: cgwalters
At this point, there are many helper functions that really should just
be made upgrader-aware to make it easier to follow. For example, now
both find_missing_pkgs_in_rpmdb() and generate_treespec() are passed the
Upgrader object directly, allowing us to avoid having to thread through
multiple arguments everywhere. Another example is that the Upgrader now
carries the list of final packages that need to be overlaid rather than
passing it around.
We also rename the functions to better reflect what they actually do.
Closes: #804
Approved by: cgwalters
Since we now use a predictable directory for the rootfs checkout and
assembly operation, there's no need for a tmprootfs variable anymore.
Closes: #804
Approved by: cgwalters
It's less cumbersome to check for this in the origin. Factor it out
there so that it's easier to modify it in the future.
Closes: #804
Approved by: cgwalters
In all cases, we always do download_metadata() followed by prepare().
Let's just make life easier for callers by inlining this in prepare(),
much like what libdnf does. The function is still public in case some
use case calls for making them separate.
Closes: #805
Approved by: cgwalters
There's not much use in having RpmOstreeInstall be separate now that
it's completely private. Let's just make it part of the main context
object rather than making callers allocate space for it and pass it to
the various context methods.
We also rename `prepare_install` to `prepare` since it will (soon) do
more than just installs (and sometimes only pure uninstalls).
Closes: #805
Approved by: cgwalters
Splitting this out before I keep hacking on this file. Pretty
straightforward stuff. There is one legitimate use of the `goto out`
pattern left in which we clean up a tmpdir.
Closes: #788
Approved by: cgwalters
This was a kind of last-minute bug introduced when I tweaked the
checkout to use `.` to avoid a `mkdir()` for files. But there were
multiple bugs with that; for files that are in subdirectories of `/etc`
we obviously need to get the right subdir and not use `/etc`.
Second, we need to handle the case where we're adding new subdirectories.
This change fixes `rpm-ostree install firewalld + rpm-ostree ex livefs`.
Closes: #783
Approved by: jlebon
There are a few different use cases here. First, for layering new packages,
there's no good reason for us to force a reboot. Second, we want some support
for cherry-picking security updates and allowing admins to restart services. Finally,
at some point we should offer support for entirely replacing the running tree
if that's what the user wants.
Until now we've been very conservative, but there's a spectrum here. In
particular, this patch changes things so we push a rollback before we start
doing anything live. I think in practice, many use cases would be totally fine
with doing most changes live, and falling back to the rollback if something went
wrong.
This initial code drop *only* supports live layering of new packages. However,
a lot of the base infrastructure is laid for future work.
For now, this will be classified as an experimental feature, hence `ex livefs`.
Part of: https://github.com/projectatomic/rpm-ostree/issues/639Closes: #652
Approved by: jlebon
I noticed I had `/tmp/rpmostree-metadata*` directories, and there
were two cases where we created those dirs. Astonishingly,
*both* had bugs that prevented cleaning up.
Rename one of them so in the future it'll be clearer which is buggy (or both).
Closes: #772
Approved by: jlebon
Before this commit, in the case where we have 3 deployments, the rollback code
would pick the merge/pending deployment. This is understandable since that logic
predates us potentially creating 3 deployments.
For livefs, I want rollback to actually go to the rollback, not the pending.
Add an API to find the pending/rollback, and put it in syscore, since we have
other similar functions to this there. (Perhaps in the future we'll figure out a
way to dedup the deployment walking/filtering logic a bit).
Port the two callers to it.
Closes: #767
Approved by: jlebon
I didn't realize we had this dbus method. It was added in the initial
drop of the DBus API, and AFAICS nothing uses it; it's not exposed
via the cmdline, and a quick `git grep` in Cockpit shows it's
not used there either.
It's tempting to delete it.
However, before we take that step, let's reimplement it in terms of the new,
shiny, more powerful "cleanup" txn.
The particular reason I'm doing this is I want to change how we handle
rollbacks.
Closes: #767
Approved by: jlebon
This is a follow-up to commit 77acf62. There, we added support for
rebasing from a local branch to another local branch. But in testing,
it's also really useful to be able to rebase from a remote-based refspec
to a local branch. We allow this here by slightly expanding the syntax
of allowed refspecs.
Now, we can use rpm-ostree all the time rather than fallback to `ostree
admin deploy`, which isn't pkg-aware.
Closes: #764
Approved by: cgwalters
While nothing else besides cleanup right now would call this directly, the code
should live close to the other very similar function:
`rpmostree_syscore_add_deployment()`.
Closes: #709
Approved by: jlebon
This is prep for livefs. We need to tweak the logic from what
core libostree has in `ostree_sysroot_simple_write_deployment()`,
and while we could land improved logic there, I think it makes
sense to carry this here until we're confident enough in the logic
to make it ABI.
This does depend on a [new libostree API](https://github.com/ostreedev/ostree/pull/745)
that allows writing deployments without doing cleanup.
The `bump_mtime()` bit is also prep for livefs, carrying in this patch to avoid
splitting things too much.
Closes: #709
Approved by: jlebon
This is preparatory for future changes which will make use the newer sysroot
writing API. But in this change, we can drop all of our version ifdef'd code.
Closes: #740
Approved by: jlebon
Otherwise dracut will just default to the running kernel, which will be
wrong if the pending deployment doesn't have the same kernel. Use --kver
rather than appending to be more explicit.
Closes: #722
Approved by: cgwalters
The new UpdateDeployment() method wraps the full capability of the
deploy transaction handler. Modifiers indicate how one wants to change
the origin, and options indicate extra behaviours.
One interesting note here is that all the options "come together" for
the first time: some of them were user-specified options (reboot,
skip-purge, dry-run), some were internal only (no-pull-base), and some
were both (allow-downgrade).
This means we now have to handle interesting cases, e.g.:
- We check for option conflicts between "no-pull-base" and
"set-refspec"/"set-revision" (similarly for "skip-purge").
- We enable "allow-downgrade" by default if the refspec or revision is
changing.
- Previously, "dry-run" could only be specified through PkgChange().
Rather than making it only valid when pkgs are overlayed (which
itself wasn't that meaningful since the introduction of dormant
package requests), we generalize it so that "dry-run" just means:
stop right before actually deploying the tree.
Closes: #711
Approved by: cgwalters
If available, using the also-new `OSTREE_CHECK_VERSION`. I dropped the `path`
argument from one of the internal APIs since it made the code simpler, and every
caller except one was passing `.`.
Closes: #712
Approved by: jlebon
All the handlers that eventually create a deploy transaction can share
much more code. This will make it easier to implement pkg
install/uninstall for all of them in one place.
Closes: #710
Approved by: cgwalters
Right now, the `rpm-ostree cleanup` logic calls into a "public static" method of
`RpmOstreeSysrootUpgrader`. That's because today, a lot of the high level "core
server side" logic lived in that class. However, it's only for upgrades (well,
really "generating pending deployments").
As I'm working on "livefs" which is really something different, I find it needs
to interact with some of `SysrootUpgrader`'s logic. Let's introduce a "sysroot
core" which is just a set of static functions taking an `OstreeSysroot*`, and
then all 3 of cleanup, (upgrade|deploy) and livefs can use these.
Closes: #708
Approved by: jlebon
Prep for livefs; there we're storing live update state as xattrs on the
deployment root, and hence we need access to the sysroot to query it.
Closes: #706
Approved by: jlebon
Rework pkg_change() so that the core functionality is implemented by a
helper function. Also convert it to the new style.
I also renamed the "local-packages" to "install-local-packages".
Contrast with the future values: "install-packages" and
"uninstall-packages".
Closes: #704
Approved by: cgwalters
This is the same change that was done for PkgChange(). It will be
required if we want to support specifying local packages through e.g.
--install switches.
Closes: #704
Approved by: cgwalters
Just like `rpm-ostree ex`, for things like `ex livefs` that have DBus
interfaces, we should segregate these off so that people know they're unstable.
And conversely that they can test for the presence of the method on the main
interface for stability.
I initially tried having the same `RpmostreeOS` object implement both
but couldn't work out how to do that; see https://mail.gnome.org/archives/gtk-app-devel-list/2017-March/msg00161.htmlCloses: #701
Approved by: jlebon
This is a follow-up to commit 81c43e8 (#657). That commit extended the
definition of "packages_added" to also support local RPMs. We revert
that here, and instead open the RPM file ourselves and send the fd over
D-Bus. We add support for a "local-packages" option containing the fd
indices to process.
It's just cleaner and safer overall; the daemon and client might not
even be sharing the same view of the filesystem!
Closes: #696
Approved by: cgwalters
Add an annotation so that the generated D-Bus code allows rpm-ostree to
pass fds through messages. Note that this doesn't change the API itself,
only how rpm-ostree uses the GDBus library. Clients should still be able
to invoke PkgChange() as before.
Closes: #696
Approved by: cgwalters
Currently we propagate the version field from the base to derived,
but the status UI shows the timestamp from the derived commit.
I found this *extremely* confusing when I was trying to reason about the
up-to-dateness of my system. The version and timestamp should be locked
together so we display them consistently.
When we generated the local commit isn't really useful information; conceptually
we have the base timestamp, plus timestamps for the rpm-md repos. We should
display the latter instead.
(This also adds `base-timestamp` and `base-verison` to the JSON; only
the former is new information, but the latter helps us be consistent)
Closes: #697
Approved by: jlebon
This takes commit c437f90 a bit further. We delete more #ifdef 0 blocks
which can just be revived later on if we need it.
Closes: #695
Approved by: cgwalters
Allow users to directly specify an RPM file on the command-line. The
"packages_added" array of the PkgChange() method can now contain
absolute paths to RPM files.
Grow the origin format to have a new "requested-local" key. This is
similar to the "requested" key, except that the packages are always
installed from cache. The "requested-local" array values also embed the
SHA-256 of the header we expect.
There is now a new "LocalPackages" line in the status. These packages
are a subset of the "packages" element (which are printed as
"LayeredPackages") and represent the packages that are explicitly marked
for installing from cache.
Interesting design choices/notes:
- Just as before, even with foo-1.0-1.x86_64 installed from RPM, a
user can still request "/usr/bin/foo": it will be made dormant. As
soon as foo stops being explicitly layered from the RPM, it will try
to fulfill the request by going to the repos. This allows users to
"pin" a layered package to a certain RPM, and then unpin it.
- The strings/NEVRAs in "requested" and "requested-local" are strictly
distinct. This allows us to be able to tell what the user means
exactly when they do "rpm-ostree uninstall".
Closes: #657
Approved by: cgwalters
Pull #646 introduced a subtle regression: we went from always including
a "packages" entry to only including it if there are packages present.
Albeit it's easy to guard against, though to be nice, let's make it
easier for consumers by always including it.
Reported-by: Micah Abbott <miabbott@redhat.com>
Closes: #670
Approved by: cgwalters
