F41 Change Proposal: DNF and bootc in Image Mode Fedora variants (system wide)

Project Discussion Change Proposals
,
1

DNF and bootc in Image Mode Fedora variants

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

Enhance the image-mode Fedora user experience by providing familiar DNF commands on client side and inside a container image build. Provide DNF5 alongside rpm-ostree while we slowly port functionality from rpm-ostree to DNF5.

DNF5 can be used in most cases during container builds (Containerfile/Dockerfiles) for a familiar UX. Initially DNF will point users to use rpm-ostree on a booted image-based/ostree system.

For Fedora 41, we will provide DNF5 on image-based Fedora variants (Atomic desktops, Fedora IoT, etc). We will update all layering examples to use dnf during build time when possible. Additionally to DNF we will still provide rpm-ostree as the main tool for package layering on the client side and bootc to manage transactional, in-place operating system updates using OCI/Docker container images.

DNF5 will provide a helpful error when running on an ostree/image-based booted system pointing to use rpm-ostree or to unlock the system.

This work is part of the Fedora Bootable Containers Initiative.

:link: Owner

:link: Current status

DNF5 when installed on a image-based/ostree system can be used to install RPMs if the system is unlocked, it also works on most container builds, one major exception at the moment are kernel installations and kernel updates. DNF is not part of image variants at the moment, however CoreOS is exploring adding it via: Ship dnf in FCOS and RHCOS · Issue #1687 · coreos/fedora-coreos-tracker · GitHub

Bootc allows system admins to deploy bootable containers and it’s available on the Fedora repositories.

:link: Detailed Description

Having the Fedora ecosystem (from users to release engineering) move away from DNF on image-based systems has had mixed results as it has forced sysadmins and users to not use DNF as they are accustomed to and learn a new tool to do RPM package management in their systems. This change proposal starts the process of making DNF the client side tool to manage RPMs on image-based systems in the future. To start we will provide the DNF5 package alongside rpm-ostree, giving sysadmins and users the ability to use DNF on their container builds and unlocked systems running image-based Fedora variants. We will also provide bootc to manage the image-based deployments and updates.

This proposes that:

  • DNF5 is included on image-based/ostree Fedora variants.
  • DNF5 is updated to point users to rpm-ostree on booted client systems when invoked.
  • rpm-ostree features will start being ported to DNF5.
  • We support deriving new user custom images from image-based Fedora images and installing software using DNF during builds.
  • We ship bootc on all Fedora image-based variants.

:link: Feedback

None so far.

:link: Benefit to Fedora

  • A familiar UX for rpms during container builds of image-based Fedora.
  • A new dedicated tool for image-based system updates management that follows the *nix ethos of using one thing and doing it well.
  • An initial use of DNF on booted image-based systems when the system is unlocked.

:link: Scope

  • Proposal owners:
    • Add DNF5 and bootc on all image-based/ostree variants.
    • Update DNF5 error message when called on a booted image-based/ostree system
  • Other developers:
    • The “other” here is vague, but certainly developing this so far has needed cooperation with e.g. the containers, coreos and dnf organizations etc.
  • Release engineering: Probably nothing needed so N/A #Releng issue number
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy: Aligns with the work to improve Image Mode variants of Fedora

:link: Upgrade/compatibility impact

Each edition/spin will include bootc and dnf(DNF5). However rpm-ostree will still be present, which means there is no upgrade/compatibility impact, we are adding additional tools not removing tools or functionality.

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? No

:link: How To Test

On a booted image-based host, run: dnf install <package> and bootc status

Inside a Dockerfile/Containerfile with a image-based Fedora variant as a base image, add a package using dnf: RUN dnf install <package>

:link: User Experience

Users of image-based Fedora variants will be able to use the dnf command on Container builds and unlocked systems.

:link: Dependencies

N/A

:link: Contingency Plan

  • Contingency mechanism: Continue to ship without DNF in some or all image-based/ostree variants.
  • Contingency deadline: Beta freeze.
  • Blocks release? No

:link: Documentation

:link: Release Notes

To be written.

Last edited by @amoloney 2024-05-21T10:25:23Z

4 Likes
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply giving that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

I have mixed feelings about merging rpm-ostree functionality into DNF5. To me it seems like building single tool for two quite different purposes. So it kinda goes against “doing only one thing well”.

Also I am afraid that having single tool with different sub-commands and options performing differently depending on what system (in what mode) it is used can cause more confusion that it solves.

1 Like
4

I’m not sure that tiny, composable tools are really an overall design goal.

Interesting — I see it as the opposite. Currently, there are two different ways to do the same thing (install and manage software). This brings that together into one tool which does that one thing.

But, I agree with the concern about the same commands acting differently in different circumstances. It’s important to get that UX right.

5

I’d like to see more of a plan here. :classic_smiley:

6

This change proposal has now been submitted to FESCo with ticket #3216 for voting.

To find out more, please visit our Changes Policy documentation.

7

Updated the section on the proposal.

8

Matthew’s position is how most of us owning the proposal see it. We are also in the process to designing the UX but that will likely take some time and is out of scope on this proposal. But you can follow the issues related to DNF/Bootc here: Issues · fedora / bootc / Issue Tracker · GitLab

9

This change has been accepted by FESCo for Fedora Linux 41. A full list of approved changes to date can be found on the Change Set Page.

To find out more about how our changes policy works, please visit our docs site.

10

My concern here remains along the lines I’ve communicated in numerous github project issues for both bootc and rpm-ostree: the base image creation process is completely forgotten/neglected here. The ostree image ecosystem needs to provide a nice, clean process for creating base images. Today rpm-ostree kind of does this via rpm-ostree compose but it is far from perfect.

To fully replace rpm-ostree, dnf5 or bootc need to gain a reasonable interface for creating base images. For my use cases I have absolutely no desire to build on top of the bloated images created by Fedora or Red Hat. It seems like all the plans I’ve seen to move away from rpm-ostree basically forget about end users creating their own base images.

Instead the candidate seems to be this trainwreck: fedora / bootc / Experimental Base Images Builder · GitLab (really need to be honest with this one). Whatever the plans are for moving away and abandoning rpm-ostree needs to get the base image creation aspect into better shape. It could be a separate tool but it needs to be comprehensible and ‘ergonomic’. What I’ve seen to date is certainly a regression from what we current get in rpm-ostree compose (which ain’t much but it can be coerced into functioning).

1 Like
11

Hi Jon, your feedback is appreciated. I don’t think this specific change proposal is relevant to base image generation though. I’ve now filed Supportable customizable base images (#32) · Issues · fedora / bootc / Issue Tracker · GitLab to track this and I’d appreciate if you can provide a bit more constructive feedback (perhaps I missed it elsewhere?) with specifically what you don’t like about the experimental builder approach.

In that issue I outlined other options, but basically please there if you can provide more information about your requirements/goals (e.g. is it just a smaller package set? How important is non-RPM content? etc.) that’d be helpful. Thanks!

1 Like
12

FWIW, I’d like to see a much smaller “ring 0” base image which consists of nothing more than what’s required to get systemd up and running in a minimal state in a VM — and that trimmed down as much as we reasonably can. (It’s really too big right now!)

Then, “ring 1” could consist of that + everything common between all Fedora Editions.

I’ve got thoughts beyond that too, but, starting there seems like it would remove a lot of the cases where a custom start might be wanted.

2 Likes
13

So, has this already arrived in F41 beta?

Does this also mean we can use dnf copr again?

Then I could retire my bash reimplementation XD (but I kinda prefer it)

14

I have switched to image-based F41 Kinoite (via rpm-ostree rebase ostree-remote-registry:fedora:quay.io/fedora/fedora-kinoite:41) and I still cannot see either dnf(5) or bootc on my system. Has this been postponed after all? Am I doing something wrong?

15

Currently, to use dnf and boots in Atomic Desktops, you will need to rebase to some of the still unofficial container images.

For Kinoite it should be quay.io/fedora-ostree-desktops/kinoite:41.

16

Sorry, I thought that was implied with “I have switched to image-based F41 Kinoite.” I did rebase before writing that comment:

$ rpm-ostree status                                                                                      ~
State: idle
Deployments:
● ostree-remote-registry:fedora:quay.io/fedora/fedora-kinoite:41
                   Digest: sha256:f9f96855ccefaae338a2263470c048e421e40311203f2e6620cb2552ba88299d

Edit: Oh, I just realized I appear to be using the wrong registry URL! Gonna try the one you suggested, thanks!

17

See What’s new for Fedora Atomic Desktops in Fedora 41 - Siosm’s blog

3 Likes
18

Right, that clears it up. Many thanks! :slight_smile: