Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#9192 - Clear up documentation (differences) on -Rs and -Rc

Attached to Project: Pacman
Opened by Ben Dibbens (ibendiben) - Sunday, 13 January 2008, 12:14 GMT
Last edited by Xavier (shining) - Thursday, 17 January 2008, 07:50 GMT
Task Type Support Request
Category Documentation
Status Closed
Assigned To Xavier (shining)
Architecture All
Severity Low
Priority Normal
Reported Version 3.1.0
Due in Version 3.1.1
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Summary and Info:

I reprased the documentation on --cascade-removal and --recusive-removal of packages as their differences, and function let to confusion with me and other users:
http://bbs.archlinux.org/viewtopic.php?id=21470
http://bbs.archlinux.org/viewtopic.php?id=35257
http://bbs.archlinux.org/viewtopic.php?id=24588
http://bbs.archlinux.org/viewtopic.php?id=13378
and I think there were more but my point should be clear.

----------------------------------------------------------
REMOVE OPTIONS

-c, --cascade
Remove all target packages, as well as all packages that depend on one or more
target packages. This operation is recursive.

Remove all target packages. Remove all packages that depended on one or more of them as well, provided that they are not required by any other (not) target packages.

-s, --recursive
Remove each target specified including all dependencies, provided that (A)
they are not required by other packages; and (B) they were not explicitly
installed by the user. This option is analogous to a backwards --sync
operation.

Remove each target package specified, provided that they are not required by any other (not target) package. Remove all of the package(s) that one ore more target packages depended on, provided that (A) they are not required by any other (not) target packages; and (B) they were not explicitly installed.
This task depends upon

Closed by  Xavier (shining)
Thursday, 17 January 2008, 07:50 GMT
Reason for closing:  Fixed
Additional comments about closing:  fixed for 3.1.1
Comment by Ben Dibbens (ibendiben) - Sunday, 13 January 2008, 12:17 GMT
Did I understand it well?
Comment by Xavier (shining) - Sunday, 13 January 2008, 13:51 GMT
Thanks for trying to improve the documentation. Reading your links to bbs, it seems a few users had troubles understanding these options indeed.
But personally, I don't find your explanation more clear, I prefer the current one.
However, something that apparently helped in the forums was providing a simple example. Maybe that would help in the man page?
Comment by Ben Dibbens (ibendiben) - Sunday, 13 January 2008, 16:20 GMT
Yes I think my explanation is not 'it' too.
An example might do the job. It seems strange now, but (also do to English not being my language) I found it hard to understand the differences between the two options.
--cascade
Does this explanation need, a note that it won't/will remove a package if it is still required?
Comment by Nagy Gabor (combo) - Sunday, 13 January 2008, 16:47 GMT
Personally I don't like -Rc at all, it is really dangerous operation <- Ben, as I see, you also misunderstood that. It can never fail, it pull new and new targets to the target list, if it cannot perform the requested operation (ie. the removal would break some dependencies.)
So if you do a "pacman -Rc gtk2" than you also remove _all_ packages depend on gtk2 (and packages depend on these packages, and so on). In worst case, it removes all of your packages ;-P

Back to your report:
I would do just a small modification in -Rs description:
Remove each target specified including all THEIR dependencies...
And imho the long form of -Rs (--recursive) is not very suggestive, --dependencies might be better.
Comment by Ben Dibbens (ibendiben) - Sunday, 13 January 2008, 18:57 GMT
If --cascade is as you say, it quite dangerous indeed D:
About Rs: Agreed
Comment by Xavier (shining) - Sunday, 13 January 2008, 21:47 GMT
Would it be any better with the following patch?
Comment by Nagy Gabor (combo) - Sunday, 13 January 2008, 22:03 GMT
Yes. Much better. I also wanted to suggest putting a big warning about -Rc to the manual.
A small note: we can also mention that -Rs is also recursive (because the long form doesn't indicate it any more), but this may be needless [this depends on how you interpret dependency]
Comment by Xavier (shining) - Sunday, 13 January 2008, 22:16 GMT
Mentions that -Rs is recursive.
Comment by Ben Dibbens (ibendiben) - Sunday, 13 January 2008, 22:47 GMT
Well done!
Comment by Dan McGee (toofishes) - Sunday, 13 January 2008, 23:44 GMT
Hmm, this makes things more confusing in my book. :)

Now we have -d/--nodeps and --deps. Something seems odd about that. The documentation updates are probably welcome though, and I will take those for now.
Comment by Xavier (shining) - Monday, 14 January 2008, 00:34 GMT
I noticed that and it seemed a bit odd indeed.
But also note that both -Rs and -Rc are recursive. And -Rs walks through the dependencies (the children in the dep tree),
while -Rc looks at the parents. So I thought that this renaming made sense.
But anyway, I wasn't sure, so if you dislike it, I am fine with it :)
Comment by Dan McGee (toofishes) - Monday, 14 January 2008, 01:26 GMT
See the following commit, it addresses the original bug:
http://projects.archlinux.org/git/gitweb.cgi?p=pacman.git;a=commit;h=6ee95afe7e9ac1b0ecdc517948ecdcc3b69ccf68

I'm hesitant to change the option names because these have been around for so long without anyone saying a peep.
Comment by Xavier (shining) - Monday, 14 January 2008, 23:34 GMT
Changing the name might do more harm than good, indeed.
I guess this can still be closed though, the man page should at least be clearer now.

Loading...