Make it easier to figure out which package, template, or ISO contains a specific bug fix (so it's easier to test specific bug fixes) #8449
Labels
C: infrastructure
C: tests
P: default
Priority: default. Default priority for new issues, to be replaced given sufficient information.
@marmarek I would really love to see
Sorry for my walls of text @andrewdavidwong but if we want to test fixes, we need to know which package version includes the fix, we need to know which template version includes the fixed packages and we need to know which ISO includes which fixed templates includes which fixed packages.
Even more for fixes correcting installer past related bad assumptions (salts, dom0, pools, LUKS, LVM, filesystem creation, block/sector assumptions etc etc etc)
Some history unrelated to this issue backing up my "meta" analysis (I was first line of support for customers at that time, let's remember this):
Nothing "installer" related problems can easily fix those issues but to backup/reinstall/restore.
Some thoughts.
Installer "tag" should encompass:
Other examples
A recent bug report to NixOS made them realize that LUKs unlocking was insecure on legacy firmware and that unlocking secret was stored unencrypted on /boot.... Reencrypting LUKS online was an option. Reinstalling is the solution.
Pool change seperation of q4.0 required a reinstall. Upgrade scripts lowered security. Let's remember that LUKS1 was effective prior or that. Reencrypting is possible to upgrade to LUKS2 but far from being recommended. users should reinstall in all case (otherwise unclear why they use Quebesos for insecure use case)
Tldr: an installer issue tag made available globally would track reinstallation requirements and track needed testing more efficiently.
Originally posted by @tlaurion in #8242 (comment)
The text was updated successfully, but these errors were encountered: