This is analogous to the dnf option of the same name, available in both
dnf4 and dnf5. It has the same semantics as rpm-ostree's `repos` key, so
we can map it directly.
This will make it easier in CoreOS-land to inject our own repos and
control enablement declaratively rather than have to fiddle with repo
files directly. Note also that the `config-manager` dnf plugin is not
installed by default in the base bootc image, and I would rather not
have to install that for each compose.
The `nobody` user/group is special and can't be driven from a sysusers
dropin because Fedora's systemd has a compiled-in default value
for naming the overflow user that same name and that always takes
precedence.
The problem is that due to legacy and cargo-culting, we have to deal
with a bunch of systems with the `nobody` user set to 99:99 that we
can't just ignore. We need to migrate those, but for now at least to
make `--sysusers` usable in these environments, let's add a new hidden
`--nobody-99` option which defines _only_ that entry in the hardcoded
passwd/group. This _is_ respected by systemd-sysusers.
See also: https://github.com/coreos/fedora-coreos-tracker/issues/1201
See also: https://github.com/systemd/systemd/issues/7717
This allows users to opt out of the hardcoded passwd/group files we
carry here in favour of making sysusers entries canonical.
This is especially useful with the `--add-dir` option, which allows
injecting user-owned sysusers entries to e.g. define more users or to
fixate normally floating UIDs from packages.
This uses the new `sysusers` knob in rpm-ostree. For more details, see:
https://github.com/coreos/rpm-ostree/pull/5427
Those are more like package requests than package names, so things like
`foo > 1.0` should be supported.
Pass the install arguments through `shlex.quote`.
We don't currently want the minimal-plus target to be user-facing. It's
intended only for other Fedora variants.
Let's support "hidden" manifests by having their names end in
`.hidden.yaml`. Then, make `minimal-plus` hidden.
I considered instead having them start with `.` to match
well-established semantics, but I don't like either that this hides them
from an `ls` in the git repo (or even with `-a`, puts them higher up
whereas I want it to be close to `minimal.yaml`).
I also considered leveraging the existing symlink hiding semantics, but
it also felt awkward to rename a file and add a symlink to it just for
the purpose of hiding it.
The `if os.path.isdir(args.manifest)` bit dates from the introduction
of this script, but doesn't really work. I suspect the intent here was
to abstract over some manifests being top-level YAML files and others
being directories).
Except that:
1. The script didn't actually check the right path. It's checking
`$PWD/{args.manifest}` instead of `$MANIFESTDIR/{args.manifest}`.
2. `list` doesn't have the equivalent logic to look for `manifest.yaml`
files in subdirectories.
3. Nowadays, there is both a e.g. `standard.yaml` _and_ a
`standard/manifest.yaml` directory. The established semantic there
AIUI is that the top-level manifests are opinionated for a specific
OS (Fedora/CentOS/RHEL), whereas the directories are shared across
all of those.
So let's just nuke support for the directory path.
Right now, the expectation for adding unpackaged content in a custom
base image flow is to do it after the main compose. The problem however
is that sometimes you want that content to affect the main compose
itself, so doing it afterwards is not sufficient.
The primary use case for this is sysusers.d dropins where you need
to make sure that sysusers in scriptlets don't pick UIDs/GIDs already
reserved on target client systems.
One way to work around this is to synthesize an RPM that ships the
dropin, and then ensure that it somehow runs as early as possible in the
transaction. This is doable but obviously quite a hack.
Enable this instead by adding a generic `--add-dir` switch which then
just translates to `ostree-layers` in the override manifest.
The dnf equivalent would be to first install e.g. `filesystem` and
`setup`, add files to the rootfs, and then install all the other
packages.
See also discussions in https://github.com/coreos/rpm-ostree/pull/5354.
As far as I can tell --cachedir was used prior to bootc-base-imagectl
being introduced in c89b6f4. Let's add the --cachedir option to
bootc-base-imagectl, but we won't use it in our Containerfile yet
because we need to wait for [1] to land in an rpm-ostree release.
This is useful today for people hacking away locally.
[1] https://github.com/coreos/rpm-ostree/pull/5391
The current custom base image flow of rebuilding a "built-in" image with
custom repos and then adding your own content separate is reasonable,
but it would be nice if one could augment the list of packages to
install in that initial build rather than as a separate transaction.
Then, you don't have to cleanup after dnf and `/var` content, re-inject
repo definitions, and refetch repo metadata. It also allows building
container images with additional packages without `dnf` necessarily
being in the package set.
We don't want to leak rpm-ostree implementation details, nor do we want
to invent a new format. So just add support for a `--install` arg and a
generic `--args-file` to pass arguments via a file.
We then generate a new treefile on the fly to extend the `packages`
list.
The prow/validate job does some various whitespace checks and
was complaining about these so I guess I'll try to make it happy:
```
[+] Found files with whitespace at the end of line
./fedora-coreos-config/fedora-bootc/.gitlab-ci.yml
./fedora-coreos-config/fedora-bootc/bootc-base-imagectl.md
./fedora-coreos-config/fedora-bootc/fedora-iot.yaml
./fedora-coreos-config/fedora-bootc/iot/manifest.yaml
[+] Found files with missing empty line at end of file
./fedora-coreos-config/fedora-bootc/bootc-base-imagectl
./fedora-coreos-config/fedora-bootc/fedora-iot.yaml
./fedora-coreos-config/fedora-bootc/iot/manifest.yaml
```
This fronts the functionality currently implemented in rpm-ostree,
for the same reason as we have `build-rootfs`; the functionality
may move elsewhere in the future.
Signed-off-by: Colin Walters <walters@verbum.org>
While "cross builds" and using a separate repos container can
feel very clean (instead of mutating the builder container)
it's actually much closer to our default intention to support building
a new version of the base image from the image itself.
So make the source root optional (i.e. it defaults to `/`).
This will improve the default UX, but also more specifically
will fix the issue that cachi2 breaks the separate source root flow.
Signed-off-by: Colin Walters <walters@verbum.org>
- Embed the manifests into the container image
- Add bootc-base-imagectl which is a tightly controlled frontend
to execute on those manifests.
For now, we don't attempt to rework how we build the standard
image to actually look like `dnf install`, but we show that
it can work.
Signed-off-by: Colin Walters <walters@verbum.org>
