On Monday, 18 June 2018 03:35:05 BST Ian Zimmerman wrote: > On 2018-06-17 18:12, Mick wrote: > > From the fine manual: > > z Zap (delete) the new config file and continue. > > So what do you do if the merge of this file is too hard and you want to > do it another time? The answer seems to be q (quit) or n (next), but > _nothing_ in the documentation says this is safe.
I see what you mean. The responsibility of not breaking your system, especially in gentoo, belongs to you, but we could all do with a bit of help from the devs. Most of these config file update commands do not tell you if you will be breaking your system when you adopt or reject some new config file content or syntax change, although enotices tend to be informative enough in this respect. Regarding the various options in dispatch-conf, this is my understanding of their relative safety: zap - deletes the new config file with its default content. You can't go back to review it to see what the devs are now proposing/mandating. If the changes between your old config and the newly emerged config are significant, you could have application/system breakage and/or missing functionality since you have not configured it. Applications and daemons you have set to start up in some runlevel can now fail at boot time - e.g. sshd - and leave you stranded. You can still re-emerge the package with --noconfmem to pull in afresh the new config file. quit - will just exit dispatch-conf. The new config files will be available for you to update to, next time you run dispatch-conf, or etc-update. The previous points regarding safety also apply to this action. Some changes in the config file can affect your system, or applications. next - will not deal at all with the current config file, just load the next config file in the queue for you to review. If there is no other config file waiting for an update it will exit dispatch-conf. Next time you run dispatch- conf the file you skipped will be there for you to review. The previous points regarding safety also apply to this action. > > For files which have a lot of changes, some of which I wish to reject > > and some to accept, I tend to use m (for merging). Again from the > > fine manual: > > > > m Interactively merge the current and new config files. > > The problem (or multiple problems) here is that it doesn't say what is > being merged into what (no, its not symmetric), and to compound that it > doesn't just leave this file alone and quit or go on to the next file; > it shows some diff again. What does this new diff mean? I can't make > sense of it without answering my other questions. While you're merging the new config content into your existing, a new temporary merge_file is created, a hybrid of the two. Until you accept it, it will not replace your old config. The second diff that comes up (if you press l) shows the changes you have accepted/rejected. It gives you a chance to change your mind and abort this merge, so you can try it again, or to return another time to review the changes. If you abort the merge_file is deleted. > To clarify: I don't think this is simply a usability problem that can be > addressed by using better or more verbose English. I think there is a > "big picture", a concept of what is being done, and this concept has not > found its way into the documentation or the UI itself. > > In particular, I suspect the developers think of it as merging my mods > into the "official" packaged versions, while I want to handle it the > other way: I see my version as the "master" or "trunk", and I want to > merge the package mods into it. > > But I really don't know. I am confused :-P I'm not sure if this is how the devs have been thinking config file updates are meant to be handled, but TBH I can't see much of a difference in the concept. When you use m to merge the files, left is your own/old configuration settings and right is the devs default settings. Until you accept/reject all or some of these your own config file stays as is. I haven't found a major difference between dispatch-conf and etc-update in their usage, the former uses letters, the latter numbers in their menu of actions. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
