Re: [gentoo-user] Re: default CONFIG_PROTECT behavior

[Mick]

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