[gentoo-user] Re: default CONFIG_PROTECT behavior
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.
Re: [gentoo-user] Re: default CONFIG_PROTECT behavior
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
Re: [gentoo-user] Re: default CONFIG_PROTECT behavior
On Tue, Jun 19, 2018 at 11:15 AM 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. > 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
[gentoo-user] Re: default CONFIG_PROTECT behavior
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
On Mon, Jun 18, 2018 at 3:27 AM Neil Bothwick 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
Re: [gentoo-user] Re: default CONFIG_PROTECT behavior
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
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.
Re: [gentoo-user] Re: default CONFIG_PROTECT behavior
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. pgpj_gSbM912_.pgp Description: OpenPGP digital signature
[gentoo-user] Re: default CONFIG_PROTECT behavior
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
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.
Re: [gentoo-user] Re: default CONFIG_PROTECT behavior
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 signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: default CONFIG_PROTECT behavior
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.
