1 |
On 07/01/2016 09:42 AM, Duncan wrote: |
2 |
> Zac Medico posted on Fri, 01 Jul 2016 08:35:26 -0700 as excerpted: |
3 |
> |
4 |
>>> But if you genuinely think this is a good idea, and someone else on the |
5 |
>>> team does too, I won't oppose it. We should make sure that we strongly |
6 |
>>> discourage its usage for regular users. Perhaps your suggested manpage |
7 |
>>> addition already does -- I don't know. |
8 |
>> |
9 |
>> Yeah, I think the warning message that I've put in the man patch is |
10 |
>> pretty good: |
11 |
>> |
12 |
>>> This option is intended to be used only with great caution, |
13 |
>>> since it is possible for it to make nonsensical configuration changes |
14 |
>>> which may lead to system breakage. Therefore, it is advisable to use |
15 |
>>> ---ask together with this option. |
16 |
> |
17 |
> Perhaps rename the option so it makes perfectly clear the possible |
18 |
> consequences? Something like --autounmask-breakme, or --auto-breakme ? |
19 |
|
20 |
My experience with my wrapper script that gives similar behavior is that |
21 |
it practically always "just works". It's fabulous for continuous |
22 |
integration (aka tinderbox) settings. However, as with self-driving |
23 |
cars, it deserves caution. |
24 |
|
25 |
> Or alternatively, if there are other arguably dangerous options now or |
26 |
> possible in the future, put them all under another option, --breakme, |
27 |
> such that if that option isn't there, the otherwise dangerous options |
28 |
> only print a warning and die. |
29 |
> |
30 |
> Then people can read the manpage if they really want to know what it |
31 |
> does, but people who haven't, aren't as likely to blunder into it due to |
32 |
> the stereotypical "rm -rf .*" type advice. |
33 |
|
34 |
It's simply not as risky as you're making it out to be. If it's a |
35 |
production system, use --ask. Honestly, people who can't be exposed to |
36 |
options like this should not have root access. |
37 |
-- |
38 |
Thanks, |
39 |
Zac |