Re: [gentoo-user] Handling of config updates, RFC
On 12 Feb 2006, at 17:40, Maarten wrote: 1) "The Gentoo Way" says that gentoo shouldn't make that decision for you. Nah. I think "The Gentoo Way" translates to... After three of four years of using Gentoo my experience is that "The Gentoo Way" translates differently depending upon the opinion(s) of the person using that expression. The definition of "sensible and intuitive behaviour" seems to vary widely & subjectively, but perhaps I'm just (still) bitter about having a DEPENDS bug rejected because someone using the prism54- firmware might conceivably not need wireless tools (if they're using kismet, for instance). Stroller. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Handling of config updates, RFC
Boyd Stephen Smith Jr. wrote: > On Sunday 12 February 2006 07:37, Maarten <[EMAIL PROTECTED]> wrote about > '[gentoo-user] Handling of config updates, RFC': > >>What tickles me the most about the current process is that one sometimes >>gets huge lists of updated files by updating a single package. A package >>which may have never been used, or at least configured, by the user. >>For instance, updating webmin, or snort, yields many many ._cfg files an >>average user knows little about, and does not care about since he never >>tweaked them. In other words, they are in their distibution-default >>state, never edited. It stands to reason everyone would want all those >>files overwritten by the new ones, is it not ? Well, neither tool does >>that now. > > > 1) "The Gentoo Way" says that gentoo shouldn't make that decision for you. Nah. I think "The Gentoo Way" translates to "You can turn this behaviour ON or OFF at your discretion". I fail to see why yet another switch in the dispatch-conf.conf would do harm to the Gentoo Way, and neither what would be the drawbacks to shipping a stage tarball with all config dates set to a predefined past date which can serve as reference point... > 2) Check out your /etc/dispatch-conf.conf; It has options to automatically > perform a number of merges and even keep an RCS history of config files to > ensure that it is easy to rollback in breaking changes. I tell > dispatch-conf to automatically merge config files I haven't touched. I do too, but it still confronts me with 80+ files I have never touched. > I'd say the tools provided with portage, plus cfg-update, as mentioned by > the other poster, as more than capable for my use (actually, the only one > I /ever/ use is dispatch-conf). Before trying to stir up development > efforts on another method, please try and fully understand the tools > gentoo provides. I'm not saying config file maintainence couldn't be > improved in gentoo, but I think it's in a state that satisfied the > majority of users and (more importantly) developers. It does help to > tweak your CONFIG_PROTECT and CONFIG_PROTECT_MASK. Okay, I'll look into that, too. I understand the developers have better things to do than go on a wild goose chase, but I really think there is room for improvement in this area. Maybe most of you run nightly or weekly 'emerge world's (and thus can easily cope with the occasional 7 files needing merging), but we run a large number of servers, and therefore we only run emerge world a couple of times a year (at most). I can tell you from experience that emerge telling you "there are 231 config files needing attention" after such an update is _very_ discouraging. Especially since fixing that is only the beginning; after that you need to fix everything that broke (and boy do things break if you run an emerge after 6 months!). I'd mention udev, or apache, or gcc, but the list has plenty of examples... Not complaining; things break and such is life. But in the process, every step that is either tedious or time-consuming or unneccessary cuts into the time and effort needed for fixing stuff later on. And I think the current process of merging configs has all three of those aspects. But that's all IMHO, of course. regards, Maarten -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Handling of config updates, RFC
Rumen Yotov wrote: > On Sun, 2006-02-12 at 14:37 +0100, Maarten wrote: > > Hi, > Check "cfg-update" it's in portage, and i think it the better. > i'm using it together with "dispatch-conf" but think if switching > completely to 'cfg-update' (or mostly at least). > Check the forums for additional info (features, history etc.) > HTH.Rumen That sounds perfect. Thank you very much for the pointer ! Maarten -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Handling of config updates, RFC
Neil Bothwick wrote: > On Sun, 12 Feb 2006 14:37:41 +0100, Maarten wrote: > > >>What tickles me the most about the current process is that one sometimes >>gets huge lists of updated files by updating a single package. A package >>which may have never been used, or at least configured, by the user. >>For instance, updating webmin, or snort, yields many many ._cfg files an >>average user knows little about, and does not care about since he never >>tweaked them. In other words, they are in their distibution-default >>state, never edited. It stands to reason everyone would want all those >>files overwritten by the new ones, is it not ? > Not. What is the default settings change. You may not have edited the > config because the old defaults were what you wanted, but the new > defaults may break your system. Your old config file, with the settings > you needed, has now gone to bit heaven and you are left with a broken > system. Hum, I'll go along in that there _may_ be changes in the default behaviour that a user may not want, but tough luck; the opposite is far _more_ likely: that the new binary can't cope with the old config, and you then also are left with a broken system. Same difference... Is is also very possible that the new binary has different behaviour regardless of config. Emerging world can, and does, change things and I would suggest that if a user doesn't want any surprises he/she shouldn't run emerge world in the first place... But apart from that, I'd even dare suggest that, when emerging a package + its config file changes the default behaviour and that change is not unavoidable (by setting the right options in the new config) that that ebuild is plain broken. There is one exception to that, however: when the change is neccessary from a security standpoint. In that case I'd say it is _good_ that the old config with the insecure setting gets overwritten. Remember, the user _did_not_edit_ the file at any point, so there should be no "expectancy of non-breakage" by an update. If a user explicitly wants to keep the config, what is wrong with him running 'touch' on all configs he wants unchanged? And besides, I never suggested that my new procedure _shouldn't_ make backups of all configs it replaces, just like dispatch-conf can do. In my case, emerge world very often breaks things, no matter if I use the old or the new config. So saying "this may break things" in very rare occasions is a bit like saying "while you're in the air falling down and both your parachutes fail to work, you also get the hiccups". ;-) > Of course, Gentoo is all about choice, so if you want to take that > change, you can set dispatch-conf to do what you want. If you say so... but it is non-obvious. Or if by that you mean I have to make a huge list of CONFIG_PROTECT_MASK files... well, that takes even more time than just running dispatch-conf and be done with it. What I'm looking for is a way to automate things a bit more. Defining a list of what may and what may not be overwritten can be quite tedious, and is by no means automatic. > # Automerge files that the user hasn't modified > # (yes or no) > replace-unmodified=no I _have_ set that setting at "yes" of course, but it works nowhere near useful... even to the point that I figured the setting was broken, or was only a stub for future enhancement... That said, cfg-update sounds exactly like what I need, so... Regards, Maarten -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Handling of config updates, RFC
On Sun, 12 Feb 2006 14:37:41 +0100, Maarten wrote: > What tickles me the most about the current process is that one sometimes > gets huge lists of updated files by updating a single package. A package > which may have never been used, or at least configured, by the user. > For instance, updating webmin, or snort, yields many many ._cfg files an > average user knows little about, and does not care about since he never > tweaked them. In other words, they are in their distibution-default > state, never edited. It stands to reason everyone would want all those > files overwritten by the new ones, is it not ? Not. What is the default settings change. You may not have edited the config because the old defaults were what you wanted, but the new defaults may break your system. Your old config file, with the settings you needed, has now gone to bit heaven and you are left with a broken system. Of course, Gentoo is all about choice, so if you want to take that change, you can set dispatch-conf to do what you want. # Automerge files that the user hasn't modified # (yes or no) replace-unmodified=no -- Neil Bothwick Spock, I though you were dead!" "I rebooted, Captain." signature.asc Description: PGP signature
Re: [gentoo-user] Handling of config updates, RFC
On Sunday 12 February 2006 07:37, Maarten <[EMAIL PROTECTED]> wrote about '[gentoo-user] Handling of config updates, RFC': > What tickles me the most about the current process is that one sometimes > gets huge lists of updated files by updating a single package. A package > which may have never been used, or at least configured, by the user. > For instance, updating webmin, or snort, yields many many ._cfg files an > average user knows little about, and does not care about since he never > tweaked them. In other words, they are in their distibution-default > state, never edited. It stands to reason everyone would want all those > files overwritten by the new ones, is it not ? Well, neither tool does > that now. 1) "The Gentoo Way" says that gentoo shouldn't make that decision for you. 2) Check out your /etc/dispatch-conf.conf; It has options to automatically perform a number of merges and even keep an RCS history of config files to ensure that it is easy to rollback in breaking changes. I tell dispatch-conf to automatically merge config files I haven't touched. I'd say the tools provided with portage, plus cfg-update, as mentioned by the other poster, as more than capable for my use (actually, the only one I /ever/ use is dispatch-conf). Before trying to stir up development efforts on another method, please try and fully understand the tools gentoo provides. I'm not saying config file maintainence couldn't be improved in gentoo, but I think it's in a state that satisfied the majority of users and (more importantly) developers. It does help to tweak your CONFIG_PROTECT and CONFIG_PROTECT_MASK. -- Boyd Stephen Smith Jr. [EMAIL PROTECTED] ICQ: 514984 YM/AIM: DaTwinkDaddy -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Handling of config updates, RFC
On Sun, 2006-02-12 at 14:37 +0100, Maarten wrote: > Hi > > I have not been impressed by the handling of configfiles (updating them) > by neither etc-update nor dispatch-conf, so I pondered on an > alternative. Not an alternative to those packages, but some extra help, > possibly integrated into one of those tools. Please bear with me... > > What tickles me the most about the current process is that one sometimes > gets huge lists of updated files by updating a single package. A package > which may have never been used, or at least configured, by the user. > For instance, updating webmin, or snort, yields many many ._cfg files an > average user knows little about, and does not care about since he never > tweaked them. In other words, they are in their distibution-default > state, never edited. It stands to reason everyone would want all those > files overwritten by the new ones, is it not ? Well, neither tool does > that now. The user is left with two options to handle the task: > 1) Pick out all non-trivial files in a massive list of over 150 files, > merge those, and after due consideration have dispatch-conf do all the > remaining files automatically. (I suspect this is what most people do) > 2) Go through all the files step by step and choose either overwrite or > skip as fast as possible, and re-run the tool on the remaining files, > and this time carefully decide what to do with it, overwrite, shred, or > merge. > Well, neither is comfortable. Especially since 'trivial merges' like > CVS- or revision info are advertized as being dealt with, but in reality > are often not. I cannot tell you how many 'changes' I get confronted > with are just trivial changes (like added commentary, and so on) > > > I propose to add an additional mechanism to 'see' whether a file was > actively changed during the lifetime of the machine, by a very simple > and dumb means, but nevertheless a very effective one. > This would work like this: upon extraction of the stage tarball (or at > least very very early in the install process) one should set all the > dates of all the potential configfiles to a set date in the (distant) > past. Let's say, feb 29 1988. Only thereafter, we start configuring the > system, editing fstab, hostname, etc. > > Now when we run dispatch-conf, it will first check the date of the file > that corresponds with a ._cfg file. If that file has that magic date, > overwrite it by the new file, and (this is important) re-set the date of > that new file to that old magic date. The user thus needn't be bothered > by numerous files he didn't touch, and a very significant time-saving is > realized for everyone. > > If I'm not mistaken, other distributions have had solutions like this > for ages. For instance, SuSE's YaST had/has a way to see if a user > touched the configfile, and refuses to touch it if it found out the user > had changed it manually. (Not a very succesful strategy for people who > routinely did edit the files, but considering all that, it was still not > bad. > > ...What do you think ? Has this idea been suggested before ? > Wouldn't this make the updating a much less painful process ? > What, if any, would be possible pitfalls using this approach ? > > Thank you for your time reading this, > > Maarten v d Berg > Hi, Check "cfg-update" it's in portage, and i think it the better. i'm using it together with "dispatch-conf" but think if switching completely to 'cfg-update' (or mostly at least). Check the forums for additional info (features, history etc.) HTH.Rumen smime.p7s Description: S/MIME cryptographic signature
[gentoo-user] Handling of config updates, RFC
Hi I have not been impressed by the handling of configfiles (updating them) by neither etc-update nor dispatch-conf, so I pondered on an alternative. Not an alternative to those packages, but some extra help, possibly integrated into one of those tools. Please bear with me... What tickles me the most about the current process is that one sometimes gets huge lists of updated files by updating a single package. A package which may have never been used, or at least configured, by the user. For instance, updating webmin, or snort, yields many many ._cfg files an average user knows little about, and does not care about since he never tweaked them. In other words, they are in their distibution-default state, never edited. It stands to reason everyone would want all those files overwritten by the new ones, is it not ? Well, neither tool does that now. The user is left with two options to handle the task: 1) Pick out all non-trivial files in a massive list of over 150 files, merge those, and after due consideration have dispatch-conf do all the remaining files automatically. (I suspect this is what most people do) 2) Go through all the files step by step and choose either overwrite or skip as fast as possible, and re-run the tool on the remaining files, and this time carefully decide what to do with it, overwrite, shred, or merge. Well, neither is comfortable. Especially since 'trivial merges' like CVS- or revision info are advertized as being dealt with, but in reality are often not. I cannot tell you how many 'changes' I get confronted with are just trivial changes (like added commentary, and so on) I propose to add an additional mechanism to 'see' whether a file was actively changed during the lifetime of the machine, by a very simple and dumb means, but nevertheless a very effective one. This would work like this: upon extraction of the stage tarball (or at least very very early in the install process) one should set all the dates of all the potential configfiles to a set date in the (distant) past. Let's say, feb 29 1988. Only thereafter, we start configuring the system, editing fstab, hostname, etc. Now when we run dispatch-conf, it will first check the date of the file that corresponds with a ._cfg file. If that file has that magic date, overwrite it by the new file, and (this is important) re-set the date of that new file to that old magic date. The user thus needn't be bothered by numerous files he didn't touch, and a very significant time-saving is realized for everyone. If I'm not mistaken, other distributions have had solutions like this for ages. For instance, SuSE's YaST had/has a way to see if a user touched the configfile, and refuses to touch it if it found out the user had changed it manually. (Not a very succesful strategy for people who routinely did edit the files, but considering all that, it was still not bad. ...What do you think ? Has this idea been suggested before ? Wouldn't this make the updating a much less painful process ? What, if any, would be possible pitfalls using this approach ? Thank you for your time reading this, Maarten v d Berg -- gentoo-user@gentoo.org mailing list
