- Because it was too much effort to pick out the few decent contributions from the misleading and wrong information. If you don't want to see such large reverts of your work in the future, then don't make such large edits with unrelated content. It's really that simple. Falconindy (talk) 18:25, 4 November 2012 (UTC)
This does not explain to me why unneeded html and other ugly formatting has to stay, why an example line only with the
autodetect hook is better than an explanation what it does, why there should be no sentence mentioning that the wrong order can leave the system unbootable, why the unconventional LUKS on LVM is preferable over LVM on LUKS, why removing
scsi has a problem if root is on a sata device, [...]! Please be a bit more carefull when reverting edits, a few sentences on a linked talk page won't hurt anyone!
- Sure, feel free to change that. Do not suggest blatantly wrong syntax like "(keymap)" in the
HOOKSarray. Falconindy (talk) 18:25, 4 November 2012 (UTC)
Trying to understand your explanation above (Most of this is no longer relevant with new lvm2) it came in my mind maybe you meant there is auto-rearrangement done by hooks that fixes in example "wrong" order of
lvm2. I don't know of that and am not going to look in the code or testing it and maybe having to chroot into an unbootable system. If you know better do appropriate changes but please don't bring back html-formatting! :-)
- Maybe you should keep up with the news before guessing at what might be right and wrong. The new LVM2 package in core and was talked about on the mailing lists and makes ordering for LVM2 irrelevant. Again, if you want to contribute or improve things fine, but do not spread misinformation. Falconindy (talk) 18:25, 4 November 2012 (UTC)
I also noticed that hooks only affecting image generation but not runtime (in example
filesystems, ...) obviously can get listed earlier or later than advised in different articles over the arch wiki. However I think it's best to explain that hooks are executed in the order listed and in general it is good practice to list any hooks in a reasonable order.
As said if you know they do not affect runtime this could get neglected but for some of them (like
filesystems) you can't know they won't need runtime capabilities in the future and/or are not expanded by users so maybe this is not even worth mentioning?
- The abhorrent table that describes the runtime and buildtime functionality of each hook sort of points out that hooks like
filesystemsdon't have a runtime component. Explaining in a circuitous fashion that some hooks can be ordered differently than others does zero good. Rather, explain the basic concepts and not the applications: what a hook is and what it consists of, and how ordering might affect each component. This would be useful information. Falconindy (talk) 18:25, 4 November 2012 (UTC)
The other part of your explanation (this edit suggests wrong syntax in HOOKS) I think you meant the brackets around
shutdown in the LVM on LUKS example line.
It is just said there in the sentence above that the keymap hook is optional and I also think it is self explanatory not to really place those brackets there. However I agree in that this is not good formatting and now tried to solve this using italics (not nice as well I personally think) with my last edit.
If you just wanted to remove the crypto content from the article because you are personally not interested in that feel free to take the Merge-Template for granted. I can do the merge if you would rather delete one and copy the other though ;-) just leave me a message here on your talk-page. Note the example line without autodetect can get removed too. As long as the templates are there this section looks unnecessary strange so I will remove the autodetect line if there comes no veto. As well I will remove the merge template if getting no feedback on this after a week or so. --Nonix (talk) 18:08, 4 November 2012 (UTC)