Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey Owen,

On Wed, 2023-05-24 at 13:50 -0400, Owen Taylor wrote:
> 
> What if we made the Toolbox container image just one more base image
> and built it with ImageFactory?
> 
>  - Integrated into the compose process
>  - Across all architectures
>  - No OSBS dependency
>  
> The main disadvantage is that it is no longer layered, so *if* you
> happen to have the exact same Fedora image version around for some
> other reason (a big if), you save a fraction of space:
>                       
> Fedora 38 container - 71M compressed, 201M uncompressed      
> Toolbox add-on layer -  232M compressed, 753M uncompressed
> Toolbox squashed  - 291M compressed, 884M uncompressed

I am not too attached to the bandwidth or space savings due to the
fedora-toolbox image being a layered image.

[ In future, I would like to  explore if we can ship the fedora-toolbox
image as part of the Silverblue and Workstation ISOs, to avoid the need
for a sizable download just to set up the default Toolbx.  That could
unlock things like defaulting to a Toolbx shell or generally help
promoting Toolbx as a primary interactive CLI environment.  Anyway,
that's a big 'if'.  ]

My main concern, which I had brought up in the Release Engineering
tickets before [1,2] is whether the fedora-toolbox images would
continue to be defined as a Docker/Containerfile.  I am asking because
the fedora base images are defined as kickstart files [3].

There's some value in continuing to use a Docker/Containerfile because
it's widely known and leads to a common workflow.  It is used for the
official Toolbx images for other distributions like Arch Linux, RHEL
and Ubuntu, and a growing list of third-party Toolbx images [4].  A
Docker/Containerfile is easy to use with 'podman build' as part of the
upstream CI, which makes it easier to test all the different parts.

Currently the Fedora and RHEL images that are shipped to users aren't
built straight from the upstream Git repository, but from the separate
copies on Fedora and Red Hat dist-git.  Even then, it's a lot easier to
manage two copies of the sources in the same format, as opposed to one
using Docker/Containerfiles and the other something else like kickstart
files.

Cheers,
Rishi

[1] https://pagure.io/releng/issue/11399#comment-853047
    Attached to this Change proposal

[2] https://pagure.io/releng/issue/11189#comment-840689
    Past discussion that led to this Change

[3] https://pagure.io/fedora-kickstarts

[4] https://github.com/toolbx-images/images
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux