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

init-cache should use same cache for host and VM #9705

Closed
DemiMarie opened this issue Jan 12, 2025 · 2 comments
Closed

init-cache should use same cache for host and VM #9705

DemiMarie opened this issue Jan 12, 2025 · 2 comments
Labels
P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. R: declined Resolution: While a legitimate bug or proposal, it has been decided that no action will be taken.

Comments

@DemiMarie
Copy link

How to file a helpful issue

The problem you're addressing (if any)

Having separate package caches for host-DIST and vm-DIST slows down downloads, wastes disk space, and provides no benefit.

The solution you'd like

Share caches between host-fcX and vm-fcX.

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

All contributors who build packages for both host and guest will benefit from not having to run init-cache as often.

Completion criteria checklist

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

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

No, this is bad idea. They are not the same. They have different repositories (or local package sets), which is especially relevant with #9703. For example host-DIST will have our Xen packages, while vm-DIST will have Xen packages from given distribution repos.

@marmarek marmarek added the R: declined Resolution: While a legitimate bug or proposal, it has been decided that no action will be taken. label Jan 12, 2025
Copy link

This issue has been closed as "declined." This means that the issue describes a legitimate bug (in the case of bug reports) or proposal (in the case of enhancements and tasks), and it is actionable, at least in principle. Nonetheless, it has been decided that no action will be taken on this issue. Here are some examples of reasons why an issue may be declined:

  • No solution can be found.
  • The proposed action is not possible.
  • The proposed action would weaken security to an unacceptable degree.
  • The proposed action would be too costly (in time, money, or other resources) relative to the benefits it would provide.
  • The proposed action would make some things better while making other things worse, and the trade-off is not worthwhile.

These are just general examples. If the specific reason for this particular issue being declined has not already been provided, please feel free to leave a comment below asking for an explanation.

We respect the time and effort you have taken to file this issue, and we understand that this outcome may be unsatisfying. Please accept our sincere apologies and know that we greatly value your participation and membership in the Qubes community.

If anyone reading this believes that this issue was closed in error or that the resolution of "declined" is not accurate, please leave a comment below saying so, and the Qubes team will review this issue again. For more information, see How issues get closed.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jan 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. R: declined Resolution: While a legitimate bug or proposal, it has been decided that no action will be taken.
Projects
None yet
Development

No branches or pull requests

2 participants