Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cages should start with cached packages already installed #9703

Open
DemiMarie opened this issue Jan 12, 2025 · 3 comments
Open

Cages should start with cached packages already installed #9703

DemiMarie opened this issue Jan 12, 2025 · 3 comments
Labels
C: builder Qubes Builder P: default Priority: default. Default priority for new issues, to be replaced given sufficient information.

Comments

@DemiMarie
Copy link

How to file a helpful issue

The problem you're addressing (if any)

Even with the Qubes executor, installing the cached packages is often the (subjectively) slowest part of a build.

The solution you'd like

Cached packages (fetched with init-cache) should be pre-installed into a chroot, avoiding the need to install the packages every time. The local and container executors can bind-mount the chroot into the cage read-only for even more speed wins, and the Qubes executor might be able to use a Plan 9 filesystem mount.

This should not be done for CI builds (and possibly production builds) because it hides missing build dependencies. That’s not an issue for developer builds, though.

The value to a user, and who that user might be

All contributors will benefit from faster builds.

Completion criteria checklist

(This section is for developer use only. Please do not modify it.)

@DemiMarie DemiMarie added T: enhancement C: builder Qubes Builder P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. labels Jan 12, 2025
@marmarek
Copy link
Member

Similar to the other ticket (and as you noted in the description), this should be opt-in.

@marmarek
Copy link
Member

And BTW, this one should be quite easy to implement, contrary to #9702 .

@DemiMarie
Copy link
Author

Similar to the other ticket (and as you noted in the description), this should be opt-in.

Should it? It definitely needs to be configurable, but I expect that most developers will have it on while CI and production builds have it off. If this does not have a security trade-off, I would expect to have the default be on, with CI and production explicitly disabling the feature. If a developer messes up a dependency, CI will catch the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: builder Qubes Builder P: default Priority: default. Default priority for new issues, to be replaced given sufficient information.
Projects
None yet
Development

No branches or pull requests

3 participants