rpm-ostree, dnf and bootc in a bootable containers world

[Joseph Marrero]

Greetings!

With all the updates that have happened with Ostree Native Containers
and Atomic desktops, we wanted to share some initial thoughts on the
direction for evolving the user experience of image-based systems and
what that means for the packages and projects that provide the
foundation for this technology.

The main tool to manage packages and upgrades on ostree systems has
been rpm-ostree. With the introduction of OSTree Native Containers and
CoreOS layering (https://github.com/coreos/layering-examples),
rpm-ostree turned into a system that also managed container-native
image upgrades and deployments. This gave us an opportunity to
reconsider `dnf` for image-based systems, a tool that Fedora system
administrators are accustomed to manage the RPM packages and introduce
`bootc`, a new tool to boot containers and manage image-based Fedora
deployments.

Rough consensus was forming around these points:

On the short-term:

* dnf4 & dnf5 should provide a more helpful error when a user types
`dnf install` on a booted image-based system (pointing them to unlock
the system or use rpm-ostree).
* `bootc` (https://github.com/containers/bootc) is now available to
manage the container/image-based lifecyle on Fedora 39 and up hosts.
* No new major development should be done on rpm-ostree; we will
provide fixes and security updates but major development for
client-side features should be directed to `bootc` for container/image
lifecycle management and `dnf` for package management.
* dnf should be used during container builds of image-based Fedora for
most applications and examples.

Long term (Maybe Fedora 43/45 timeframe...):

* rpm-ostree client-side functionality handling package
layering/install/overrides should be folded into dnf.  (A *lot* of
details here)
* rpm-ostree will continue to be part of the ostree/ostree-container
base image composes. However this will be re-assessed after dnf has
become the default client-side tool for image-based Fedora systems.

As part of the UX we want dnf to continue to be the tool that
sysadmins see as the way to manage their RPM packages, even on
image-based systems. Some specific features of bootc to manage the
image lifecycle like `bootc upgrade` might be wrapped by `dnf upgrade`
on image mode systems, however we see bootc as the main tool to manage
the image-based hosts' deployments and we don't plan to hide this from
the customers behind dnf.

Our intent with the Fedora Change proposal is to cover the initial UX
changes, add bootc and  and re-introduce dnf on image-mode variants.
The new proposal builds on top of functionality added on these
previous enhancements:

* OstreeNativeContainer:
https://fedoraproject.org/wiki/Changes/OstreeNativeContainer
* OstreeNativeContainerStable:
https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable

If you would like to share feedback you can reach out to us via the
methods outlined at
https://docs.fedoraproject.org/en-US/bootc/community/ and you can
follow the new change proposal here:
https://fedoraproject.org/wiki/Changes/DNFAndBootcInImageModeFedora

Signed off by:
    - David Cantrell
    - Jonathan Lebon
    - Colin Walters
    - Timothée Ravier
    - Joseph Marrero

[Petr Pisar]

V Mon, May 20, 2024 at 02:15:49PM -0400, Joseph Marrero napsal(a):
>  * dnf4 & dnf5 should provide a more helpful error when a user
> types
>  `dnf install` on a booted image-based system (pointing them to unlock
>  the system or use rpm-ostree). 
[...]
>  * dnf should be used during container builds of image-based Fedora
> for
>  most applications and examples.
>   
How is it that DNF is not good enough for users, but at the same time it's
good enough for building the images?

-- Petr

[Stephen Smoogen]

On Tue, 21 May 2024 at 03:18, Petr Pisar <ppisar(a)redhat.com&gt; wrote:

>  V Mon, May 20, 2024 at 02:15:49PM -0400, Joseph Marrero napsal(a):
>  > * dnf4 & dnf5 should provide a more helpful error when a user types
>  > `dnf install` on a booted image-based system (pointing them to unlock
>  > the system or use rpm-ostree).
>  [...]
>  > * dnf should be used during container builds of image-based Fedora for
>  > most applications and examples.
>  >
>  How is it that DNF is not good enough for users, but at the same time it's
>  good enough for building the images?
>
>  
My guess was that automatic builds will have an unlocked layer and failure
to have one means that something broke in the build system before then and
needs to be fixed. The error message wanted to be added would help the
release engineers also diagnose the problem and look for a fix.



>  -- Petr
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>  

-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren

[Joseph Marrero]

On Tue, May 21, 2024 at 7:53 AM Stephen Smoogen <ssmoogen(a)redhat.com&gt; wrote:
>  On Tue, 21 May 2024 at 03:18, Petr Pisar <ppisar(a)redhat.com&gt; wrote:
> >
> > V Mon, May 20, 2024 at 02:15:49PM -0400, Joseph Marrero napsal(a):
> > > * dnf4 & dnf5 should provide a more helpful error when a user types
> > > `dnf install` on a booted image-based system (pointing them to unlock
> > > the system or use rpm-ostree).
> > [...]
> > > * dnf should be used during container builds of image-based Fedora for
> > > most applications and examples.
> > >
> > How is it that DNF is not good enough for users, but at the same time it's
> > good enough for building the images?
> >
>
>  My guess was that automatic builds will have an unlocked layer and failure to have one
> means that something broke in the build system before then and needs to be fixed. The
> error message wanted to be added would help the release engineers also diagnose the
> problem and look for a fix.
>
>  
DNF does not understand image mode/ostree systems yet, however in a
container build we are not in an ostree deployment which allows you to
just run DNF or move files as needed. There is an effort to port the
functionality from rpm-ostree to DNF but this will take time.

--
Joseph Marrero