Say which customizations tree wins, and document marking a boot file to keep - #181
Open
darksidemilk wants to merge 1 commit into
Open
Say which customizations tree wins, and document marking a boot file to keep#181darksidemilk wants to merge 1 commit into
darksidemilk wants to merge 1 commit into
Conversation
…to keep Three gaps the page did not cover. The two-trees table said what each directory IS but not the rule that makes them different. The rule is the point: /opt restores by ABSENCE, /etc adopts by PRESENCE, and that is why one directory could not do both jobs -- adopting by presence would let a backup FOG made for itself outrank a freshly shipped file, and restoring by absence would let a certificate you deliberately placed be ignored the moment FOG shipped one of the same name. "Yours to place" reads as a promise about where you put a file. It is a promise about the NAME: what FOG saves is everything in the live directory the shipped source tree does not contain. The corollary was missing and is easy to get wrong, so it is now a warning callout -- name a file bzImage and FOG wins. kernel-backups/keep/ and the Keep button were not documented anywhere. Added under Kernels and inits, with the two reasons it exists: a per-release sibling is deliberately not part of a numbered generation, and marking one of the six default names achieves close to nothing. Also separates being FOUND (header magic, any name, no configuration) from being KEPT, which are different questions that read like one. Plus a note that each readme.txt is FOG's own and may be rewritten, since FOG can now correct its own text -- and that editing one stops that for good. Companion to FOGProject/fogproject#1703.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Companion to FOGProject/fogproject#1703, which is the code half. Three gaps this page did not cover.
The two-trees table said what each directory is, but not the rule that separates them. The rule is the interesting part:
/optrestores by absence — a saved file goes back only when the rebuilt tree no longer has it — and/etcadopts by presence, overriding what FOG would generate. That is why one directory could not do both jobs: adopting by presence would let a backup FOG made for itself outrank a freshly shipped file, and restoring by absence would let a certificate you deliberately placed be ignored the moment FOG shipped one of the same name."Yours to place" reads as a promise about where you put a file. It is a promise about the name. What FOG saves is everything in the live directory that the shipped source tree does not contain, so the name is what earns the protection. The corollary was missing and is the easy thing to get wrong, so it is now a warning callout — name a file
bzImageand FOG wins.kernel-backups/keep/and the Keep button were not documented anywhere. Added under Kernels and inits, with the two reasons it exists rather than just the mechanics: a per-release sibling such asbzImage.5.15.0is deliberately not part of a numbered generation, so without a mark it survives only until the next upgrade; and marking one of the six default names achieves close to nothing, since picking up the new kernel is the point of an update.That section also separates two questions that read like one — being found (FOG classifies by header magic, so a hand-compiled kernel under any name reaches the Host Kernel dropdown with nothing to configure) from being kept (the naming rule, or a mark).
Plus a note that each
readme.txtis FOG's own text and a later version may rewrite it, so it can correct itself — and that editing one stops that permanently. That behaviour is what #1703 adds.Docs only. No code, no build changes.
🤖 Generated with Claude Code
https://claude.ai/code/session_01XNj39e7pDke6Rr6Whxin9U