(since the fedora-toolbox component is marked inactive: filing under toolbox) Once a Fedora release is done the main fedora repo basically never changes, only the updates repo. So if the fedora repo metadata was kept in fedora-toolbox, it seems it would save some time the first time dnf is run inside the toolbox, on the other hand the updates repo should not be cached in the image (specially later after GA). This is of course a optimization though it could improve the UX of fedora-toolbox. On the other hand it is not useful for rawhide or branched development... Reproducible: Always
Do you have any estimates on how it might affect the size of the fedora-toolbox images when downloading them over the network? This might be a trade-off between the first download and the first DNF experiences. We are making some significant changes to how the fedora-toolbox changes are built as part of https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker In short, we are looking at building them from a kickstart file instead of a Dockerfile so that they can be integrated into the Fedora composes. It might be wise to wait for the dust to settle before making any changes to the images.
(In reply to Jens Petersen from comment #0) > (since the fedora-toolbox component is marked inactive: filing under toolbox) I wonder why is that? :) Is it related to the changes for https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker ? I didn't see anything odd in https://src.fedoraproject.org/container/fedora-toolbox
(In reply to Debarshi Ray from comment #1) > Do you have any estimates on how it might affect the size of the > fedora-toolbox images when downloading them over the network? This might be > a trade-off between the first download and the first DNF experiences. I _think_ it is roughly 72MB, so something to factor in too, though the image is already so big now that it probably doesn't matter? > We are making some significant changes to how the fedora-toolbox changes are > built as part of https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker > In short, we are looking at building them from a kickstart file instead of a > Dockerfile so that they can be integrated into the Fedora composes. It > might be wise to wait for the dust to settle before making any changes to > the images. Agreed (In reply to Debarshi Ray from comment #2) > (In reply to Jens Petersen from comment #0) > > (since the fedora-toolbox component is marked inactive: filing under toolbox) > > I wonder why is that? :) > > Is it related to the changes for > https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker ? I didn't see > anything odd in https://src.fedoraproject.org/container/fedora-toolbox I suspect so, but not certain - I only found the related releng tickets/discussion after filing this. If we get daily refreshes of fedora-toolbox for current releases, that would be a nice plus IMO.
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening. Since the Change to kickstart files: https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker ... the fedora-toolbox images are now defined as Kiwi descriptions: https://fedoraproject.org/wiki/Changes/KiwiBuiltCloudImages https://pagure.io/fedora-kiwi-descriptions It's relatively easy to run Kiwi locally, which helps with experiments like this. @Jens: do you have time to see if the 'fedora' DNF repository metadata can be included in the fedora-toolbox images? CCed Neal, who knows a lot more about Kiwi than I do.
Another alternative is to expose the 'fedora' DNF repository metadata from the host through toolbox(1), as long as the host and the container have matching Fedora versions.
It is not possible because the repository isn't available to run "dnf makecache" inside of Koji, since Koji doesn't have internet access.
(In reply to Neal Gompa from comment #7) > It is not possible because the repository isn't available to run "dnf > makecache" inside of Koji, since Koji doesn't have internet access. So iiuc dnf is no longer involved, so there is no dnf cache generated and deleted. In that case we can probably just close this CANTFIX.
(In reply to Jens Petersen from comment #8) > (In reply to Neal Gompa from comment #7) > > It is not possible because the repository isn't available to run "dnf > > makecache" inside of Koji, since Koji doesn't have internet access. > > So iiuc dnf is no longer involved, so there is no dnf cache generated and > deleted. You mean DNF5 no longer uses a cache as before?
I mean I suppose then that base container images are built with Kiwi without using dnf. In theory mounting the host cache could still be considered, though I am not sure it is worth the effort/complexity. Also not sure if it would interact well with dnf?
(In reply to Jens Petersen from comment #10) > I mean I suppose then that base container images are built with Kiwi without > using dnf. Well I am not certain about this, but that was my assumption here.
(In reply to Jens Petersen from comment #10) > I mean I suppose then that base container images are built with Kiwi without > using dnf. I see. I do expect Kiwi to use DNF. I visualize building with Kiwi as the equivalent of building with Kickstart files or OpenShift Build Service or OSBuild. > In theory mounting the host cache could still be considered, though I am not > sure it is worth the effort/complexity. > Also not sure if it would interact well with dnf? Yes, these are the questions I had in mind. eg., what happens if two different DNF processes are updating the cache at the same time? If the answers aren't obvious, then one way to proceed could be to check how much time is saved by sharing the cache. If the savings aren't substantial then maybe it's not worth worrying too much about, and if they are, then we could look deeper into it. You already said that the cache is about 72M. Is this the right way to measure it: $ du -sh /var/cache/dnf/fedora-6c3a9e5977a00788/ 20M /var/cache/dnf/fedora-6c3a9e5977a00788/
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.
(In reply to Debarshi Ray from comment #12) > (In reply to Jens Petersen from comment #10) > > I mean I suppose then that base container images are built with Kiwi without > > using dnf. > > I see. I do expect Kiwi to use DNF. > > I visualize building with Kiwi as the equivalent of building with Kickstart > files or OpenShift Build Service or OSBuild. > It absolutely uses DNF, it just tries to ensure the cache isn't included in the final image by using bind mounts to the cache location.