Taylor R Campbell <riastr...@netbsd.org> writes: > The critical part I had missed is that certctl can claim _either_ a > directory it has already claimed, _or_ an empty directory, so it works > for new installations and to update pristine but old installations.
Sorry, I should have said that out loud; I was thinking that. > Let me know if any of this seems wrong, or if the implementation seems > to behave differently from what I described. Sounds good. > Regarding etcupdate: I agree that interactive prompting is bad for > deployment. I don't actually use etcupdate myself, partly because it > is too interactive but mainly because it can't do three-way merges -- > instead, I use a bespoke script called etcmerge that does three-way > merges using the old and new etc.tgz. > > https://mumble.net/cgit/campbell/etcmerge > > (Maybe some day I will propose to import this into base, but it needs > a lot more polish and testing first, and some tweaks to the usage > model which currently has too many things going on at once.) You may also wish to look at etcmanage, which has a concept of marking things manually maintained and handling all sorts of cases. But it does not merge. So some logical merge of all of these would be good. > But while I agree with your criticism of etcupdate, it's what we have > in base and what we recommend in the guide. So that's what we have to > work with as a baseline to gauge the impact of changes like this on > update procedures; it's hard to meaningfully gauge if I have to guess > everything that anyone might try to do. Yes, it's the standard approach, but there are a number of well-known update workflows. > That said, you're right that it's better not to create things that > rely on the interactive prompt. Thanks for adjusting; I think we're in a good place now.
