Gentoo Archives: gentoo-portage-dev

From: Pacho Ramos <pacho@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] About some settings to auto-replace with dispatch-conf
Date: Tue, 15 May 2012 21:08:23
Message-Id: 1337111209.3731.17.camel@belkin4
In Reply to: Re: [gentoo-portage-dev] About some settings to auto-replace with dispatch-conf by Pacho Ramos
1 El mar, 15-05-2012 a las 21:43 +0200, Pacho Ramos escribió:
2 > El mar, 15-05-2012 a las 08:31 -0700, Zac Medico escribió:
3 > > On 05/15/2012 04:15 AM, Pacho Ramos wrote:
4 > > > Hello
5 > > >
6 > > > I recently installed Gentoo on my uncle's laptop and he was a bit
7 > > > annoyed about needing to run "dispatch-conf" and merge a lot of changes
8 > > > on files nobody ever touched.
9 > > >
10 > > > Looking to /etc/dispatch-conf.conf I noticed options to improve this
11 > > > situation exist, but they are disabled by default. I would want to
12 > > > confirm if they are safe enough or could cause problems. Options are:
13 > > >
14 > > > # Automerge files comprising only whitespace and/or comments
15 > > > # (yes or no)
16 > > > replace-wscomments=no
17 > > >
18 > > > # Automerge files that the user hasn't modified
19 > > > # (yes or no)
20 > > > replace-unmodified=no
21 > > >
22 > > > Looks really surprising to me that "replace-wscomments" is not enabled
23 > > > by default as merging that changes shouldn't hurt at all. About
24 > > > "replace-unmodified", if it works as intended, it should also be safer
25 > > > to get it enabled by default as would prevent breakage if people forgets
26 > > > to run dispatch-conf, reboot and, for example, sees some init.d script
27 > > > fail to start.
28 > > >
29 > > > Thanks a lot for the info
30 > >
31 > > FEATURES=config-protect-if-modified is what you really want. We could
32 > > probably enable it by default, but we should ask for comment on the
33 > > gentoo-dev mailing list before doing that.
34 >
35 > Didn't know about that option, thanks for pointing it :D
36 >
37 > About trying to enable it by default, I think would make sense per
38 > previous exposed reasons (and I am sure there are more examples that
39 > could show that behavior is better than keeping obsolete config files by
40 > default)
41 >
42
43 Just noticed the problem of current behavior after updating my chroot to
44 generate emul packages and needing to review 40 files with
45 dispatch-conf, all of them never touched and all of them needing to be
46 updated to new version

Attachments

File name MIME type
signature.asc application/pgp-signature