FS#10683 - Pacman -Rs instead of pacman -R by default
Attached to Project:
Pacman
Opened by Moises Baca (Benzo) - Tuesday, 17 June 2008, 19:55 GMT
Last edited by Xavier (shining) - Thursday, 26 June 2008, 08:18 GMT
Opened by Moises Baca (Benzo) - Tuesday, 17 June 2008, 19:55 GMT
Last edited by Xavier (shining) - Thursday, 26 June 2008, 08:18 GMT
|
Details
What if pacman uses pacman -Rs by default instead of pacman
-R?
When you install a program you want, you install all the necessary dependencies to make the program you want works with just a: # pacman -S "program" When you uninstall it you should also get rid of those dependencies without noticing because you never wanted to have them but just the program you wanted to install works, something like: # pacman -R "program" (and it should work like the actual pacman -Rs "program") I think is much more common to erase a program with all its dependencies than erase just the program and leave its dependencies installed in you computer, so to erase a program leaving its dependencies should be done by an extra option of R, like: # pacman -Rk "program" (from keep dependencies) for example and it will do the actual pacman -R "program" Also its more symetrical: # pacman -S "program" installs everything to have "program" working # pacman -R "program" erases everything that was installed to have "program" working An extra idea is that newbies would ask less how to keep their system clean. |
This task depends upon
Closed by Xavier (shining)
Thursday, 26 June 2008, 08:18 GMT
Reason for closing: Won't fix
Additional comments about closing: The current behavior is fine, it is justified and is not inferior to the one proposed, so there is no reason to change.
(change can also confuse existing users and break existing scripts)
Thursday, 26 June 2008, 08:18 GMT
Reason for closing: Won't fix
Additional comments about closing: The current behavior is fine, it is justified and is not inferior to the one proposed, so there is no reason to change.
(change can also confuse existing users and break existing scripts)
alias pacR='pacman -Rs'
Done.
1. You are seeing -R as the parallel option to -S; I see -R as a parallel option to -U which doesn't do anything with dependencies. Thus the default behavior for a remove operation would be different for both of us.
2. -Rs will always prompt the user for confirmation, just as -S does. -U/-R currently never prompt for confirmation, which is another reason I think of these two operations as a pair.
3. Changing the behavior of -R that has existed for so long will present problems for script users and human users alike. Having to learn a new option is a bit odd, and these proponents of keeping it the old way are a lot less likely to speak up now, but we will definitely hear from them after the fact. So the amount of support for this change is awfully hard to judge as those people that are fine with the current behavior are a lot less likely to speak up.
# pacman -S "program" installs everything to have "program" working
# pacman -R "program" erases everything that was installed to have "program" working (considering -R as -Rs)
2. If this new way to do things is adopted it wouldn't hurt anybody, you can always find the packages in the cache unles you erase them, and otoh it would be more intuitive for the new users. Actually it would be a relief for new and old users to get rid of the useless packages automatically.
3. This feature request was reported to get to the users, maintainers, devs, etc, to be discussed and hopefully adopted, we cannot presume a priori that only the ones that want the change will speak up and consequently the opinions will be biased. That's a fallacy.
You want your request to be discussed, yet you just killed the discussion.
Anyway, I also understand the intention of this feature request, but in my opinion both behavior have their advantages, there is not one clearly superior to the other.
So in that situation, it makes sense to just keep the behavior that works and that many people are already used to.
Sometimes, the dependencies are useful by themselves. Suppose I install smplayer, which is a mplayer frontend and thus depends on it. Later I decide that I only want to use mplayer directly and that I no longer need smplayer, so I remove smplayer. Having mplayer being removed as well in that situation would not be intuitive for the new users, and they would have to learn and use that -k option.
Finally, I don't see what is the big deal about having a few unused dependencies installed. The only thing it does is using a few mega, then what?
And just because you are no longer using these dependencies right now does not mean you will never reinstall some applications that require them later on.
New users will have to learn -k as they now have to learn -s, but I think, this automatic option will work for them most of the time, and even better, they might never have to learn -k because is not something so common and they can live without it.
In one point of using Arch they realize that got a lot of orphans in their system and they got to learn: pacman -Qdt and then pacman -Rs every package which is definitly worst.
Finally, I did read and understand Dan's comment :)
1) Arch cares about new users not willing to learn
2) Having a few orphans on the system has to be avoided at any cost
And your whole justification for this change seems to be based on these two points.
You made another point, which is the only one I found interesting and considered valid, that -R should be more symmetrical to -S.
And Dan answered that only valid concern, saying that he was more seeing -R as symmetric of -U.
There is no place to argue here, these are two different point of views which both make sense.
disadvantages - advantages = disadvantages
advantages - disadvantages = - advantages
Training is required, i.e learning of the new option. For scripts, users that want a dependency and know that -Rs would be leaving it alone, and other cases alike. With regards to symmetry, once you base it off -U/-A and not -S, the entire arguement is nullified, hence leaving a neutral stance; not enough reason to implement.
As for disadvantages of the current position, -Rs; one has to make an alias and there are packages left on the system that the user may not know about - which isn't harmful per se. And..that's it :)
I agree with him after a little though. -R is a local operation and should match -U as much as possible. It is not much extra work to use -Rs when you uninstall. Just make it a habit. Add some info to the Beginner's Guide or something.
Here's a good example: How many times do you use "rm -r" to remove a directory, without thinking twice. It's just habit because you know the argument is needed for what you want to do (remove a dir). The same goes for "ln -s" and many other things (cp -r, cp -a, makepkg -f, makepkg -fc, ...).
Hardly ever: right click, send to trash... lol. just a joke
Well I got to admit that the other point of view (the one of everybody except me) is valid too and in this case it's better that things remains the same.
I thought about your idea to improve the Beginners Guide but somebody has already added a line about this specific topic (or you guys are too fast for me?)
What I liked the most of this is that it was nice anyway to interchange ideas, this wasn't no because simply not.