Arch Linux

'N' as a default is safer..Nothing but hitting the 'Y' key should be interpreted as a 'Yes', I suppose. The choice in pacmn.conf would be nice

Safer doesnt mean saner though. When i hit enter i expect the command to be executed.

There's an argument to be made for either behavior, which is why the user should be given the option. I'm not suggesting that pacman's out-of-the-box behavior should change, but I can't see the harm in at least providing the choice.

Defaulting to 'no' is sane for programs that can potential break your system (package managers, partitioners, filesystem utilities, etc.)

Greg-
Good point. I can see most people feeling the same. An option in pacman.conf to control the default would be nice.

PLease file pacman bugs in the pacman tracker...

Sorry about that! I'll remember in future.

Formerly there was an option to tweak all the default answers, but the syntax was a nightmare, pacman expected an array of bits with default answers: for example, 00101100b. So this possibility was removed.

The problem is, that pacman doesn't use a _general_ default answer, the default answer depends on the actual operation and we have to keep in mind, that --noconfirm always "choose" the default answer. The default answer is no with "dangerous" operation only (HoldPkg etc.), I don't see why we should default to no, when the _user_ runs "pacman -R foo"...

> Defaulting to 'no' is sane for programs that can potential break your system (package managers, partitioners, filesystem utilities, etc.)

partitioners and filesystem utilities are much more dangerous imo. It can damage your data, and it's often very difficult, even nearly impossible to get it back.

package managers in the worst case make your system unbootable, nothing that you cannot repair by booting in another *nix system (which can be a livecd) and fix things there. Well there are some cases where this is not practical, eg with remote servers, but then the incompetence of a server admin is not pacman's fault.

What Nagy said is also very important : the default action is not always yes, it depends on the question.

We could still have one simple option which says the default action will be no for all the questions, but well..

Perhaps a flurry of default_ options in pacman.conf would satisfy?

Attached a sample txt file with all the current defaults.

If we allow this, would probably be a good idea to list the pros and cons of changing each option. Otherwise, make sure the default option in official pacman is always the safer option.

I guess we would need something like that if we wanted to provide an option to tweak all the default answers.
But do we really want that? Do we need this complexity?
Who is going to implement this to satisfy 2 users who have a very special need?

Maybe we need to address the primary concern instead of adding flexibility.

Are all of the current defaults safe or are they just (semi)sensible "I said -Su damnit!" defaults?

My main concern here is that if we do change any defaults without adding flexibility is that automated scripts might not get the results they used to get. Changing expected behaviour is usually bad in the short term.

In my opinion, the current defaults are safe and sensible enough, many ppl are used to them and satisfied with them.
I don't see any reason to change them and break the existing pacman wrappers.

I made this suggestion thinking that it would not be difficult or disruptive to implement, and that a number of users would appreciate having such a feature; it's looking like neither of these assumptions were correct. If no one else has any interest in the idea, perhaps this request should be closed.

People in my position (constantly switching between package managers) should probably just get in the habit of always typing 'y' or 'n' instead of relying on default choices.

I'm going to give this a bash. Hopefully the result will be clean enough that there's no objections. ;)

I would personally dislike seeing so many options added to pacman.conf... but I will wait and see how clean the patch looks

Hello all,

As suggested in thread closing comment, I have created the necessary patch (attached with the comment) for this.

Requesting to open this thread and apply patch after testing.

(NOTE: Comment below is long but I am just trying to describe properly, actual patch is small - just 11 new lines added in total)

First I would like to mention that this patch does NOT change the default behaviour.

So I request to those who have objection to this feature, please do not to object, as it does not change anything for you. Thank you :-)

Details about this patch:

1) Patch just adds one OPTIONAL directive called "DefaultAnswer". (pacman.conf)
2) If its not specified, it just behaves like current behaviour.

3) Value of DefaultAnswer can be "smart" (default) or "safe"

4) "smart" means just like current behaviour i.e. pacman decides smartly if default answer should be Yes or No.

5) "safe" means pick option which does not change anything in system. (conservative approach)

6) If safe is on, Answer to question on -U, -R, -S etc will default to NO (except when importing keys which by default is yes)

7) This option can also help new users to learn pacman and prevent accidents when they are learning.

8) noconfirm overrides this, So existing scripts should not have problem even if DefaultAnswer is set to "safe" in pacman.conf

9) Looking at code I noticed that there are two EXACTLY same functions called yesno() and noyes().
i.e. just difference is yesno has YES default, noyes has NO default.
About 7-8 lines of code is redundant.

10) So I have merged these two function in single function called yesno(int preset, ...).
If preset is 1 it is equivalent to yesno(), if preset is 0 it is equivalent to noyes()

11) This same modified yesno() function NOW decides what to do based on DefaultAnswer.


Basically there is not much logical change in yesno() code (minor 3-4 line change, overall just 11 lines added).

Once again - default behaviour is same as it is right now.

So please accept the patch and apply it to master.

Thank you.

I have created the patch needed (as asked in closing reason) which satisfies everyone. So requesting to reopen this.

I don't really understand the reasoning behind this. If you just want to know what packages an operation would affect, pacman has the --print option and provides the checkupdates script, both of which have the added advantages of not requiring root privileges or modifying the databases. It also seems fundamentally backwards for the default response to be to NOT do the thing you just told pacman to do. If you want safer behavior, I would instead suggest a setting to remove the default action altogether so that the user MUST provide an answer unless --noconfirm is used. That way we don't have to worry about figuring out which prompts should be changed.

Hmm, see its user's choice. Some users want it that way. (Like me and 2-3 others here). Its not going backward.

We want safer defaults. By your logic I can say, why even ask for confirmation at all when you just told pacman to something why not simply do it?

Everyone does alias rm='rm -i', why? To be little bit safer. Pressing simply Enter defaults to NO even in rm.

Sometimes I just want to see what packages will be downloaded (as dependency). If I remove package what else will get affected (what depends on it). etc. etc. (I dont really want to do anything!)

I know there are other ways but I dont want to remember multiple commands (like checkupdates).

All I want is one command does it all. All I want to remember is -S and -R thats all (and their sub-commands)

Atleast it makes my life easier. I already have so many other commands to remember. Hence I am looking for safer defaults.

I am not saying change the existing behaviour but atleast give us option.

Btw, I dont want to complicate things, but with little modification my patch can also implement Andrew's idea. (a 3rd angle to this feature request)

DefaultAnswer = nodefault

which will mean that user will HAVE to type y or n and there will be no default.

Everyone does not alias rm='rm -i'. IMO, that would be really, really annoying. You keep making unwarranted assumptions about how people use things.

Having users start and abort a transaction as root just to find out what packages would be installed or removed is a poor design, which is why pacman already has the --print option I mentioned before. So, I do not consider that use case a compelling justification for this feature. Avoiding "dangerous" defaults is more compelling, but the idea of what defaults are "safe" is subjective and will vary from user to user. Your own patch considered importing keys safe even though that disagrees with your own definition of a safe default as an "option which does not change anything in [the] system". Hence, I would instead prefer an option that avoids uncertainty by disabling defaults altogether.

Personally I prefer even "Import Keys" should default to "No" (because Yes means change system)

But I left it AS IS, because I felt that many users would object to that. There are already so many objections that one more objection would cause rejection of patch, so I tried to play safe.

But I think, whatever you do, there will be some people who will say this is not required, this is not how it should be.

3-4 people here wanted safe option, developers asked for patch. I created patch.

I have put my case, to accept it or not is left to developers. Thanks :)

Ok. I have further modified my patch (21 new lines added in total including previous patch) which implements Andrew's suggestion as well.

DefaultAnswer = nodefault means There will be no default answer, user has to specify yes or no. (noconfirm still overrides this)

The patch also fixes a minor bug in question() function.

On keyboard H is right in between Y and N, So if user types say H (by mistake), it takes it as N. (Does not matter if default is Y or N).

Anything other than Y (or yes) is taken as No. Now I dont know if that is correct on function level.(Function does not know what question is so can not assume that wrong input always means No)

So I fixed this as well. If user types anything other then Y or N, it asks again.

Thanks and regards.

As your patch implements it, I don't see how you would even document the "safe" option that *sometimes* defaults to the response that doesn't change the system and sometimes the response that does, other than documenting the effect on each individual question. I don't think some questions even have a "safe" answer, like handling replaces, because it depends on the exact circumstances. I still think trying to find and provide a set of defaults sufficiently safe for pacman to officially endorse them as such across the board is not worth the effort, if even possible. Unless somebody can provide a compelling criteria for what a "safe" response is that covers all cases, I think any option that promises safe defaults is more likely to cause confusion and lead to problems when people rely on it where they shouldn't.

Ok, lets not do anything just because it does not cover everything (No software can ever have everything, it builds overtime by implementing things, getting end-user response and then further modification).

Here you are trying to find complete solution before implementing and taking user opinions. That too for a feature which is not even enabled by default. (So its not like its going to cause major problems for Arch users)

The end-users who want this "safe" feature, atleast they get MAIN defaults as safe. Something is better than nothing right?

I will say implement the feature, if users think that certain "safe" option is not really safe let them file bug reports. Then we can re-view.

Pacman 4.2.0 is released. I am not sure if there is any decision made by package owner (Allan?) if to include this feature or not.

But since he had asked someone to create a patch, which he will review, here I am again. Attached is the patch for 4.2.0.

What patch does is already described in my earlier posts above

In summary:
1) Patch adds option called DefaultAnswer = smart|safe|nodefault. "smart" is default and functionality remains as if patch is not applied.
2) Currently if user presses invalid key by mistake (say H i.e. neither Y nor N) then it assumes Yes. I have fixed this as well.
3) Two almost identical functions yesno and noyes are replaced by one single function yesno

So requesting again to consider the feature.

Thank you

PS: Using the patch from about 8 months.