From ArchWiki
Revision as of 18:58, 1 March 2012 by JonnyJD (talk | contribs) (version comparision: new section)
Jump to: navigation, search

Reasoning for Existence of Page

We already have --help for a quick description of commands, and the man page for a detailed description. So what does this wiki page achieve exactly? shining 16:45, 27 April 2008 (EDT)

After last cleanup from toofishes which removed a bunch of flags, and linked to --help and man page instead, I think it is now clearer.
This page should just be a quick overview of the most frequently used pacman commands, not an exhaustive enumeration of every single flag. shining 07:50, 12 June 2008 (EDT)
Good points. Additionally, after the article refers users to the pacman.conf man page for configuration instructions, it goes on to discuss it! It would be more appropriate to remove all configuration settings as it implied, and stick with pacman and its commands.
To make matters worse, the article doesn't even discuss all about pacman; leaving out huge and important chunks of information regarding the databases, their relationships, program lists, the backend application, etc. etc. (See following section.) Perhaps someone more knowledgable could flesh it out a little, starting with the basics. It would be greatly appreciated. - KitchM 12:52, 5 November 2010 (EDT)

It may very well be that this page does not need to exist. As it is, it isn't complete and will not likely be so anytime soon. Since it has been taken over as someone's personal project, perhaps we should start working on a community wiki page on the subject of pacman. Any ideas on what we might call it? - KitchM 20:16, 8 November 2010 (EST)

This page does need to exist. Package management is a major aspect of using Arch Linux and will be represented in some way on ArchWiki.
This page is a community wiki page. Suggestions? Please provide the complete wikitext you wish to see included.
-- pointone 16:24, 9 November 2010 (EST)
You're not serious, are you? If it were an actual community project, anyone in the community could work on it without authorizaton from the self-appointed god of Arch Wiki. - KitchM 20:24, 11 November 2010 (EST)

Detail missing

Can someone please add the details of pacman? There is no explanation of how it works. What are the components and their interaction? And how about related dependencies and libraries? Without that basic flow-chart concept in mind, it is very difficult to understand the roll that third-party additions or frontends might play.

This would be very interesting. libfetch, libalpm, etc. manolo 15:23, 15 November 2009 (EST)
There's a tiny bit on Allan's blog. Details regarding libalpm should be in a separate wiki article. -- Karol 13:13, 10 February 2012 (EST)
Some more, pretty low level, info, also from Allan's blog. -- Karol 13:24, 11 February 2012 (EST)

No RTFM or personal opinions

Get rid of any comments that direct people to man pages instead of actually explaining things. That is a very lazy way of doing things. At the very least you can summarize, or you can let someone else do it.

Do not forget that one of the reasons the wiki exists is give the reader something they can understand in simple language. Man pages are the worst example of writing that has ever been written.

Also, don't make claims about how wonderful a program is; rather state the reasons for the way it was created and let the user be the judge of if it is actually wonderful or not. - KitchM

We are trying to direct to man pages as much as possible in order to avoid duplicated effort.
We do the best we can at explaining things in man pages. If people find that things are not clear, we would much prefer to get feedback, rather than people duplicating the documentation on the wiki.
The people working on pacman and its man pages actually also check this wiki page and maintain it occasionally. We would like to avoid having to fix things in both places systematically.
I hope that is understandable. We do want to explain things. We should just prefer do that in one centralized place. shining 12:10, 1 October 2009 (EDT)
Thanks, Shining, for your thoughts. I think that centralization has been the intent for many decades, but has never been correctly implemented.
IMHO, I have found that man pages are written in geek-speak by the programmers who make the software as a quickie way to document themselves to others of their language, and wiki pages are to be written by people whose job it is to communicate with everyone. I am not convinced that there is any duplication of effort in the two, but rather the necessary translation which must be done from one language to another. That is why one should only refer to man pages as an extra reference, but not the main one.
By the way, one example of problems with man pages is the recent one I ran across for pacman. Man pacman had one little reference to man pacman.conf at the bottom of the text. I had overlooked it for a long time, and only stumbled upon it by accident. Coulda, shoulda, woulda just doesn't have any bearing in this case. Poorly written, poorly formated and poorly cross-referenced is the best to which man pages can attain. There are many non-personal reasons for this, but suffice it to say, that's the way it is. Worse yet, even between the two there were still many important questions left unanswered.
I maintain that we should fully explain as we go so that mistakes like this do not occur, else the wiki is incomplete. - KitchM 11:33, 4 October 2009 (EDT)
You seem very negative and biased against man pages. You didn't even try to have them improved. We would really like to receive more detailed feedback on them before giving up. Please join to discuss this. That way, more people could also contribute to this discussion. Mails are also a much better way to discuss than a wiki page.
Did you try the web version of the man pages ? This seems well formatted and cross-referenced to me : pacman.8.html. shining 12:22, 5 October 2009 (EDT)
Could it be that the bias is on your part? I plainly wrote that as a person with experience in this area, I recognize the frustration of the billions of people who suffer from the terse and odd language of the traditional man pages. I also wrote that I have always stood ready to assist in any way to translate these things into useful common English and that few take me up on that.
I do not think that your erasure of my comments should justify contrary statements on subjects I have already addressed. Why do that?
In any case, this is the place to make comment about the problems in the wiki writing found on the referenced page. Please keep that in mind as I point out that man pages should have no place in a wiki setting as a substitute for doing proper wiki writing. I would hope that we can all agree to that, and repair the wiki page in question.
(As to the issue of helping with the man pages, as I have twice stated, all you had to do was ask. I will gladly meet you there.) KitchM 14:35, 5 October 2009 (EDT)
shining wrote: We would really like to receive more detailed feedback on them before giving up. Please join to discuss this.
KitchM wrote: all you had to do was ask. I will gladly meet you there.
Seems we are going around in circles... Allan
I don't think that is completely accurate. Sure, I was forced to restate some points, but we got thru it. And the good thing was that I got asked to help. (Which I did, by the way.) So that's real progress. And very cool. I hope my suggestions got to the right parties and were appreciated. KitchM 19:53, 6 October 2009 (EDT)

Official name?

~Also, what is pacman's official name? i.e., pacman or Pacman? manolo 00:42, 13 November 2009 (EST)

It appears as "pacman" on both the man page and the home page. -- pointone 12:35, 13 November 2009 (EST)

Pacman refuses to delete corrupted package, because it is corrupted...

I had this issue today with two packages (icu-4.4-2-x86_64.pkg.tar.xz and ttf-bitstream-vera-1.10-7-any.pkg.tar.xz). Got asked "<X> is corrupted. Do you want to delete it? [Y/n]" and then told "failed to commit transaction - <x> is invalid or corrupted". Some nice person should add in "Troubleshooting" that in this case one can delete said package manually as root in /var/cache/pacman/pkg. -- Misc 20:17, 17 April 2010 (EDT)

I'm glad someone asked this. And thanks for the pointer. One of the most annoying things that I've found users have ever had to deal with in the last couple decades has been this sort of problem with automated package management methods, regardless of the OS used. I have noticed, however, that the download process usually weeds out the corrupted downloads before committing them to the install process. It might be that dumping a bad package might be something that is automated by the pacman routine in a better manner than it does now, but downloading again, and overwriting the bad one, should fix the problem without further effort. - KitchM 23:01, 18 April 2010 (EDT)

proposed addition to package cache cleaning...

Comment: I think people will find value if the following was added to the page. Might be good to insert it between the pacman -Sc and pacman -Scc descriptions. What do others think?

Alternatively, the [CacheClean] python script can be used to manage one's pacman cache. Functionally, the script acts like the "pacman -Sc" command with a key difference: the user can select how many old versions (generations) of his/her packages to keep. For example, the following command will keep two versions of the cached packages, deleting everything else in the /var/cache/pacman/pkg directory.

# 2

- graysky 16:18, 28 May 2010 (EDT)

Disagree; I think we should keep these kinds of unsupported tools, etc. in pacman Tips. -- pointone 18:07, 2 September 2010 (EDT)
I see it has been added at the end of Pacman#Additional_commands. Maybe we should mention paccache from pacman-contrib instead? -- Karol 13:02, 10 February 2012 (EST)

Changes with pacman 3.4

In the Installing and/or Upgrading sections, we could mention the new possibility of: pacman -Syu <package> D garbage 06:26, 27 June 2010 (EDT)

Already included: Pacman#Additional_commands; closing. -- Karol 12:40, 10 February 2012 (EST)

Troubleshooting: manually reinstall pacman



IMO it should be added to this page. You can get text from [1]. --Beroal 13:13, 8 November 2010 (EST)

-Qm Command

I didn't know this existed until I found it on the forums, and found that executing it produced 3 packages that were no longer official.

1. Please sign your edits.
2. It's in the manpage, under 'QUERY OPTIONS'
      -m, --foreign
          Restrict or filter output to packages that were not found in the sync database(s). Typically these are
          packages that were downloaded manually and installed with --upgrade.
3. "it produced 3 packages that were no longer official" - so? -- Karol 21:11, 9 April 2011 (EDT)

Post upgrade tasks

Since I've been using Archlinux, I've noticied that there are some tasks that must be done after a system upgrade, I've put together'em in a script, could we add it (or something similar) to the upgrade section? (It requires meld and sudo tools)

PD. I've to add a space between brackets ( [ [ and ] ] expressions) to avoid generate links

Fixed with <nowiki> tags. -- Karol 10:20, 15 May 2011 (EDT)
 echo "* Looking recursively for *.pacnew en /etc ..."
 pacnew=$(find /etc -type f -name "*.pacnew" 2>/dev/null)
 for config in $pacnew; do
   # Merge with meld
   sudo meld ${config%\.*} $config
 if [[ "$MELD" != "" ]]; then
   echo "  Recursively delete /etc/*.pacnew? (y/N)"
   read CONFIRM
   if [[ "$CONFIRM" == "y" ]] ; then
     echo "* Recursively deleting *.pacnew from /etc/"
     find /etc/ -name "*.pacnew" -exec sudo rm {} \;
   echo "  Not found"
 HUERFANOS="`pacman -Qdtq`"
 if [ "$HUERFANOS" != "" ]; then
       echo "* Deleting orphan packages..."
       sudo pacman -Rsn $HUERFANOS
 echo "* Deleting packets' cache..."
 sudo pacman -Sc
 echo "* Done."
 echo ""

--RkG 08:53, 15 May 2011 (EDT)

pacman -Sc? Why? This way you deprive yourself of an easy way to downgrade.
Everyone can use the tools he likes best to deal with .pacnew and .pacsave files. Scripts such as yours belong to your user wiki page (RkG), not to the pacman article. -- Karol 09:57, 15 May 2011 (EDT)
Thanks for the tags; the fact is that there are some tasks that the user SHOULD do after an update (review *.pacnew files), others are CONVENIENT (delete orphan packages), and others could be interesting, like the "pacman -Sc" command (anyway it asks for a confirmation)... Ok the article says about read the pacman's log, but this things happens so frequently that could be mentioned explicitly IMO --RkG 02:51, 16 May 2011 (EDT)

pacman -Sc and package downgrading

Shouldn't the "Warning: Only do this when certain that Downgrading Packages will not be a necessity, as pacman -Scc removes all packages from the cache" be copied above # pacman -Sc with this modification: "Only do this when certain that Downgrading Packages will not be a necessity, as pacman -Sc removes also all the old versions of installed packages"? -- Kynikos 11:05, 15 May 2011 (EDT)

I think there once was a discussion about this and I'm for explicitly stating that pacman -Sc removes also all the old versions of installed packages. I would also like to have it in the manpage (I'm working on in right now). -- Karol 17:24, 15 May 2011 (EDT)
It's just a guess, but maybe you're referring to this discussion a little above? If so, my proposal does not involve scripts of any sort, only another warning; I agree that scripts should stay in Pacman Tips. If you were talking about another discussion, I don't know :) -- Kynikos 18:47, 15 May 2011 (EDT)
I was referring to this thread. The last post nicely sums things up:
'pacman -Sc" will remove packages for anything that is not currently installed. That includes:
a) packages for programs that are not installed.
b) packages for programs that are installed, but in a different version.
-- Karol 19:48, 15 May 2011 (EDT)
I see, thanks. Well, now we just have to wait for the intervention of some admin passing by... ;) -- Kynikos 10:49, 16 May 2011 (EDT)
...and Pointone freed us, I'm copying the warning. -- Kynikos 04:53, 17 May 2011 (EDT)
The second warning sounds redundant now, I'd remove it. -- Kynikos 05:00, 17 May 2011 (EDT)
Are you talking about the one above pacman -Scc? I would keep it. I always found it a bit unsettling that pacman -S<something> removes stuff. It's a sync operation, right? -- Karol 12:29, 17 May 2011 (EDT)
Ok, this is one of the first pages that users read when approaching Arch, it's better not to leave anything unexplained. -- Kynikos 04:50, 18 May 2011 (EDT)

Rewording request

Upgrading packages starts with pacman is a powerful package management tool, but it does not attempt to "do everything", as it were: is this sentence correct? Especially the as it were at the end is not very clear for a non-native speaker. Can somebody reword it a bit? -- Kynikos 07:23, 6 June 2011 (EDT)

I think we just need a link to the page about merging pacnew files, that's about the only thing pacman doesn't attempt to do thestinger 11:20, 6 June 2011 (EDT)
Do you mean Pacnew_and_Pacsave_Files? I agree, but I don't understand how it answers my original question ^^ -- Kynikos 14:25, 6 June 2011 (EDT)
Whoops. I didn't fully read what you said xD. thestinger 15:31, 6 June 2011 (EDT)
I suggest removing the 'as it were' part. -- Karol 15:05, 6 June 2011 (EDT)
My attempt to improve that section. thestinger 15:51, 6 June 2011 (EDT)
Well done, it's much clearer now :) -- Kynikos 18:06, 6 June 2011 (EDT)

Move pacman-key FAQ to pacman-key page?

pacman-key has its own page, so maybe we should move [2] and the next FAQ item to Pacman-key#Troubleshooting? -- Karol 12:36, 10 February 2012 (EST)

+1 from me. -- Kynikos 08:52, 11 February 2012 (EST)
Done, closing. -- Karol 14:35, 28 February 2012 (EST)

version comparision

I needed to know what pacman is doing with versions like 1.2.fb9 and 1.2.fb10. The documentation was not clear on that.

Short: I found fb9 is really less than fb10.

It took me a while to find, so I place the links here: version.c source and alpm_pkg_vercmp description. This is what is used. It tries to split the version in only-numeric and only-alpha parts. --JonnyJD 13:58, 1 March 2012 (EST)