[gentoo-user] default CONFIG_PROTECT behavior

[gentoo-user] default CONFIG_PROTECT behavior

[Ian Zimmerman]

What happens to files within the scope of CONFIG_PROTECT if I don't
execute dispatch-conf or any similar thingy?  I have found the confusion
the latter tool generates completely unsurmountable.

What I'd prefer is the debian behavior: the package supplied config file
is simply saved under a mangled name (*.dpkg-dist alongside the real
file on debian) and I'm left to merge the changes at my convenience,
with my preferred tools.

And maybe that's what portage already does, but I'm not sure.  If yes,
where is the package supplied file saved?  Is it under
/etc/config-archive?  The wiki makes the impression that
/etc/config-archive is specific to dispatch-conf.

So that's my question in a nutshell: after emerge but before
dispatch-conf, where are the new versions of config files?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] default CONFIG_PROTECT behavior

[Andrew Udvare]

[-- Attachment #1.1: Type: text/plain, Size: 1131 bytes --]

On 06/17/2018 12:17 PM, Ian Zimmerman wrote:
> What happens to files within the scope of CONFIG_PROTECT if I don't
> execute dispatch-conf or any similar thingy?  I have found the confusion
> the latter tool generates completely unsurmountable.

I think the side-by-side merger is very easy for small changes. Most of
the time I press z because I don't need the new changes.

> What I'd prefer is the debian behavior: the package supplied config file
> is simply saved under a mangled name (*.dpkg-dist alongside the real
> file on debian) and I'm left to merge the changes at my convenience,
> with my preferred tools.

You are free to do that. The files are named alongside the real files,
and they start with '._cfg'. Before I knew about dispatch-conf,
sometimes I would do:

for i in ._cfg*; do mv "$i" "${i/._cfg}"; done

> 
> So that's my question in a nutshell: after emerge but before
> dispatch-conf, where are the new versions of config files?
> 

find /etc/ -iname '._cfg*'

Or what dispatch-conf does:

find /etc -iname '._cfg????_*' ! -name '.*~' ! -iname '.*.bak' -print

-- 
Andrew


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: default CONFIG_PROTECT behavior

[Ian Zimmerman]

On 2018-06-17 12:42, Andrew Udvare wrote:

> On 06/17/2018 12:17 PM, Ian Zimmerman wrote:
> > What happens to files within the scope of CONFIG_PROTECT if I don't
> > execute dispatch-conf or any similar thingy?  I have found the
> > confusion the latter tool generates completely unsurmountable.

> I think the side-by-side merger is very easy for small changes. Most
> of the time I press z because I don't need the new changes.

It's not the merge step itself (sdiff) that is confusing, it's what
dispatch-conf does afterward with the result.  When you used it the
first time, did you understand what "zap new" means?

And yes, I was driven to ask this after I got an update that wasn't
"small".

> find /etc/ -iname '._cfg*'
> 
> Or what dispatch-conf does:
> 
> find /etc -iname '._cfg????_*' ! -name '.*~' ! -iname '.*.bak' -print

Thanks for this information.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

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

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

On Sunday, 17 June 2018 18:08:48 BST Ian Zimmerman wrote:
> On 2018-06-17 12:42, Andrew Udvare wrote:
> > On 06/17/2018 12:17 PM, Ian Zimmerman wrote:
> > > What happens to files within the scope of CONFIG_PROTECT if I don't
> > > execute dispatch-conf or any similar thingy?  I have found the
> > > confusion the latter tool generates completely unsurmountable.
> > 
> > I think the side-by-side merger is very easy for small changes. Most
> > of the time I press z because I don't need the new changes.
> 
> It's not the merge step itself (sdiff) that is confusing, it's what
> dispatch-conf does afterward with the result.  When you used it the
> first time, did you understand what "zap new" means?

From the fine manual:

 z      Zap (delete) the new config file and continue.


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.


> And yes, I was driven to ask this after I got an update that wasn't
> "small".
> 
> > find /etc/ -iname '._cfg*'
> > 
> > Or what dispatch-conf does:
> > 
> > find /etc -iname '._cfg????_*' ! -name '.*~' ! -iname '.*.bak' -print
> 
> Thanks for this information.


-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Peter Humphrey]

On Sunday, 17 June 2018 18:12:11 BST Mick wrote:
> On Sunday, 17 June 2018 18:08:48 BST Ian Zimmerman wrote:
> > On 2018-06-17 12:42, Andrew Udvare wrote:
> > > On 06/17/2018 12:17 PM, Ian Zimmerman wrote:
> > > > What happens to files within the scope of CONFIG_PROTECT if I don't
> > > > execute dispatch-conf or any similar thingy?  I have found the
> > > > confusion the latter tool generates completely unsurmountable.
> > > 
> > > I think the side-by-side merger is very easy for small changes. Most
> > > of the time I press z because I don't need the new changes.
> > 
> > It's not the merge step itself (sdiff) that is confusing, it's what
> > dispatch-conf does afterward with the result.  When you used it the
> > first time, did you understand what "zap new" means?
> 
> From the fine manual:
> 
>  z      Zap (delete) the new config file and continue.
> 
> 
> 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.
> 
> > And yes, I was driven to ask this after I got an update that wasn't
> > "small".
> > 
> > > find /etc/ -iname '._cfg*'
> > > 
> > > Or what dispatch-conf does:
> > > 
> > > find /etc -iname '._cfg????_*' ! -name '.*~' ! -iname '.*.bak' -print
> > 
> > Thanks for this information.

I don't have any of those problems. I still use etc-update, and if there are 
complex updates I edit the original file myself, using the diff as a guide.

I never did get to grips with the more "modern" ways of doing it.

-- 
Regards,
Peter.

[gentoo-user] Re: default CONFIG_PROTECT behavior

[Ian Zimmerman]

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.

> 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.

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

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

On Sun, 17 Jun 2018 19:35:05 -0700, Ian Zimmerman wrote:

> 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.
> 
> 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.

There are other config managers that handle this differently, if you
don't like etc-update try another. I tried a few some years ago and
settled on conf-update, others swear by cfg-update. conf-update lets you
configure the diff and merge programs it uses but I stuck with the
defaults except for using colordiff. Merging is interactive so you can
choose whether you accept your old setting or the new default for each
change. Like you, I treat my settings as the default and generally only
merge in new additions to the config or changed defaults.


-- 
Neil Bothwick

Microbiology: staph only.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Mick]

[-- Attachment #1: Type: text/plain, Size: 4271 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Daniel Frey]

On 06/17/18 15:38, Peter Humphrey wrote:
> I don't have any of those problems. I still use etc-update, and if there are 
> complex updates I edit the original file myself, using the diff as a guide.
> 
> I never did get to grips with the more "modern" ways of doing it.
> 

Same here, I tried dispatch-conf once and was like "WTF is it doing" and
went back to etc-update...

Dan

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

[Rich Freeman]

On Mon, Jun 18, 2018 at 3:27 AM Neil Bothwick <neil@digimed.co.uk> wrote:
>
> There are other config managers that handle this differently, if you
> don't like etc-update try another. I tried a few some years ago and
> settled on conf-update, others swear by cfg-update.

Since nobody else is shilling it, I will.  I don't think I could stand
Gentoo without cfg-update.  When I run Arch in a container it makes me
want to port it (maybe Arch has a similar solution - I don't use it
enough to know).

With the automatic 3-way merges 95% of the time I don't even look at
config file changes.  If the parts of the files I've customized
haven't changed, then the diff gets re-applied.  Once in a while I get
a merge conflict and then meld pops up showing me a 3-way diff.

I'll admit that it has a few issues.  One is that it isn't obvious how
to handle manual 3-way merges.  The right version is the new upstream
file.  The left version is your current file.  The middle is the
previous upstream file, so the diffs on the left show what you changed
before, and the diffs on the right show what upstream changed.
Chances are you'll want to pass through some of those, so just hit all
the merge-to-left buttons on those.  I usually just save the new file
and don't touch the previous two, so that cfg-update correctly saves
the original upstream file for re-use.  However, perhaps I should be
saving a new middle version merged with the upstream.  I haven't
confirmed exactly how it behaves.

Upstream is largely dead on cfg-update, and I'm basically nursing it
along since I can't live without it.  Feel free to give it a shot.

In the beginning it won't be much better than dispatch-conf, until it
builds up its library of past changes.

Oh, the other tool you'll want to use is etckeeper to manage /etc in a
git repo and auto-commit changes/etc with package manager hooks.  That
is a cross-distro tool, and will save your butt if you mess something
up.

-- 
Rich

[gentoo-user] Re: default CONFIG_PROTECT behavior

[Ian Zimmerman]

On 2018-06-18 11:34, Rich Freeman wrote:

> Oh, the other tool you'll want to use is etckeeper to manage /etc in a
> git repo and auto-commit changes/etc with package manager hooks.  That
> is a cross-distro tool, and will save your butt if you mess something
> up.

I already do this, only without any packaging/wrapping like etckeeper,
just bare git.  It's why I want to skip all the the gentoo merge
thingies, get a crack at the updated file shipped with a package, insert
this into git on a parallel branch, then merge in the git way.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

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

[Rich Freeman]

On Tue, Jun 19, 2018 at 11:15 AM Ian Zimmerman <itz@very.loosely.org> wrote:
>
> On 2018-06-18 11:34, Rich Freeman wrote:
>
> > Oh, the other tool you'll want to use is etckeeper to manage /etc in a
> > git repo and auto-commit changes/etc with package manager hooks.  That
> > is a cross-distro tool, and will save your butt if you mess something
> > up.
>
> I already do this, only without any packaging/wrapping like etckeeper,
> just bare git.  It's why I want to skip all the the gentoo merge
> thingies, get a crack at the updated file shipped with a package, insert
> this into git on a parallel branch, then merge in the git way.
>

Yeah, that certainly works, and if you're disciplined it has the
advantage that your git history will always be clean and reliable.

The advantage of etckeeper is the PM hooks.  If you have uncommitted
changes in /etc when you run emerge it will just dump them all into an
auto-described commit so that you don't end up with a big pile of
modified files with no history.

If you always manually review all your changes and commit them
dutifully after every update, then I believe etckeeper should behave
as one big NOOP.  It really only kicks in if you're lazy about
committing your changes, to ensure that they don't pile up.  Then if
you have an issue you can at least look at the changes since the last
time you ran emerge, or the time before that, and so on.

Personally I use a hybrid approach.  When I go deliberately modifying
config files I make my own clean commits with the stuff I know is
good.  Then I let etckeeper just merge in the daily cruft that I'm not
really intentionally touching anyway.  That means that the commits
with real descriptions are known-good, and the rest are
potentially-useful snapshots I can make use of if they work.  But,
this is all at home - I'd be more disciplined on a system I cared
about.  Well, then again on a system I cared about I'd probably be
using ansible or whatever and not upgrading in-place anyway.

-- 
Rich

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

[Kai Peter]

On 2018-06-19 17:15, Ian Zimmerman wrote:
> On 2018-06-18 11:34, Rich Freeman wrote:
> 
>> Oh, the other tool you'll want to use is etckeeper to manage /etc in a
>> git repo and auto-commit changes/etc with package manager hooks.  That
>> is a cross-distro tool, and will save your butt if you mess something
>> up.
> 
> I already do this, only without any packaging/wrapping like etckeeper,
> just bare git.  It's why I want to skip all the the gentoo merge
> thingies, get a crack at the updated file shipped with a package, 
> insert
> this into git on a parallel branch, then merge in the git way.

Not sure that it could solve your issue ... but I wrote a tool that - at 
least for me - solves all the issues with etc-update and friends.

In general the usage of sdiff is terrible to me. So I did my own 
solution. Unfortunately it is not ready to publish it, but if it is 
perhaps of interest to you have a look at 
http://gentoo.dyndn.es/doku.php/utils:qrtconf. This page describes 
mainly the concept and isn't really finished. If it would be worth to 
give it a try to you let me know and I will share it. For me it works 
since a few years with some development.

Kai
-- 
Sent with eQmail-1.11 beta

[gentoo-user] Re: default CONFIG_PROTECT behavior

[Ian Zimmerman]

On 2018-06-19 19:40, Kai Peter wrote:

> In general the usage of sdiff is terrible to me. So I did my own
> solution.  Unfortunately it is not ready to publish it, but if it is
> perhaps of interest to you have a look at
> http://gentoo.dyndn.es/doku.php/utils:qrtconf. This page describes
> mainly the concept and isn't really finished. If it would be worth to
> give it a try to you let me know and I will share it. For me it works
> since a few years with some development.

I'll definitely take a look soon.  Thanks!

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.