From ArchWiki
Jump to navigation Jump to search


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


There are (as of this writing) two places on this page which say that pacman's output is logged to /var/log/pacman.log. Obviously in the strictest sense this is false, as can easily be seen by anybody who's glanced at this file and at pacman's on-screen output. Ordinarily, this wouldn't be a problem, as it's clear what is meant. But there's also some information which is not logged, and this fact is unclear.

I'd edit the page to make it clear what is and isn't logged, but I'm not sure myself. It seems like the following things are logged:

  • Package installation complete
  • Most but not all of the per-package notices pacman prints.

It seems like the following things are not logged:

  • Progress bars (of course)
  • Package download
  • Package integrity and signature checks
  • File conflicts
  • Disk space checks
  • Optional dependencies

Unless there's a problem (in which case they may be logged; I'm not sure), you really don't care about any of these except the optional dependencies, and those can be obtained with pacman -Qi or expac. However, I'm not sure if this list is exhaustive, and wouldn't want to find out the hard way that I'd missed important pacman output by assuming it'd be in the log.

Can somebody link to (or put here) a more comprehensive list of what is and isn't logged? I haven't been able to find one, and I think that it'd be much better to be clear than to simplify by saying "all the output is logged". DHouck (talk) 08:14, 22 February 2014 (UTC)


Perhaps it best to remove sections that suggest to use whoneeds from pkgtools-git package because pkgtools-git needs gem2arch which needs ruby-erubis that does not install because *I think* they hardcoded some path wrong.

Perhaps link to pacman-tips page? which has scripts to the same actions natively.

makepkg -s
==> Validating source files with sha1sums...
    erubis-2.7.0.gem ... Passed
==> Extracting sources...
==> Entering fakeroot environment...
==> Starting package()...
ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - /home/sindhus/software/aur/ruby-erubis/pkg/ruby-erubis/usr/bin
==> ERROR: A failure occurred in package().
This is true only for pkgtools-gitAUR, pkgtoolsAUR depends on gem2archAUR only optionally. pkgtools page links to both of these packages. -- Lahwaacz (talk) 19:12, 29 August 2014 (UTC)

Exit codes

I think that pacman exit codes should be also added here but don't know them. All I have noticed so far are only 0 when everything downloaded/installed without any problems and 1 when packages where skipped. Any special exit codes when at least one package was installed while other was skipped? And why error code is 0 when failed to connect to update mirrors error: failed retrieving file, does it has the error codes when it was able to download all files to update from mirrors or not all repositories were available, e.g. only one? And may be some more exit codes for debugging?

-- Andy Crowd 08:00, 9 January 2015 (UTC)

This is something that belongs in the manual. I'd suggest filing a bug. -- Alad (talk) 17:20, 20 August 2015 (UTC)

Pacstrap issue

Moved from Beginners' guide. -- Alad (talk) 06:11, 20 February 2015 (UTC)

I don't know how many others are experiencing trouble when issuing the pacstrap -i /mnt base base-devel command but I got a series of GPGME ERROR: no data errors. This post helped: You need to run: rm -R /mnt/var/lib/pacman/sync and try again the pacstrap command. —This unsigned comment is by Sudoku (talk) 11 February 2015. Please sign your posts with ~~~~!

Don't rush updates

This edit removed a warning that was, IMHO reasonably, suggesting not to upgrade a stable system without having the time to do possible post-upgrade maintenance. I agree that the warning wasn't very well worded and could have been simplified and given a more neutral tone, however I'd reintroduce it, thoughts? — Kynikos (talk) 08:05, 18 August 2015 (UTC)

I thought the wording was fine, and the example of giving a presentation was well-chosen to communicate the small but non-negligible amount of time required to fix problems. Herodotus (talk) 20:10, 18 August 2015 (UTC)
The original warning is anything but constructive though. Compare to Enhance_system_stability#Read_before_upgrading_the_system. -- Alad (talk) 03:30, 19 August 2015 (UTC)
How about this. I'm not an expert so I mostly borrowed stuff from the deleted section and Enhance_system_stability#Arch_Specific_Tips_2. Herodotus (talk) 06:55, 19 August 2015 (UTC)
In my view, the new section had the same problems of the removed warning, plus it duplicated part of what is already written shortly above.
[2] (which replaces the new section) is my proposal instead.
Kynikos (talk) 10:51, 20 August 2015 (UTC)
Looks good to me. I do wonder if we should merge this to Enhance system stability#Read before upgrading the system and link from here. After all, potential issues on upgrade are not inherent to pacman (though resulting file system operations, or the interruption thereof, could damage the system), and Enhance system stability has some more notes on where upgrades could go wrong. -- Alad (talk) 17:10, 20 August 2015 (UTC)
I think we need a new "Recommended package management practices" section/page to cover the parts related to Arch packaging specifics from the end-user's point of view. This would describe basically Pacman#Upgrading_packages (merged with Pacman#Package_updates_have_broken_my_system), System_maintenance#Package_tasks, Enhance_system_stability#Arch_Specific_Tips and Enhance_system_stability#Arch_Specific_Tips_2 unbiased from the "enhancing stability" requirements. For the description of "why" it should refer to Arch packaging standards (or a more general overview, which I think belongs to Official repositories), rather than The Arch Way. If we can move there also the general parts of pacman#Troubleshooting, either as another "recommended practices" or a justification for them, it would be even better.
Just to make it clear, the general idea behind moving the content out of pacman is to let the main page cover only the basics related to pacman itself and describe the packaging details on a separate (sub)page like Downgrading packages or pacman tips. Of course all the pages have to be properly interlinked.
-- Lahwaacz (talk) 19:39, 20 August 2015 (UTC)

Pacman - An Introduction

In my opinion, pacman is the most important page for a newcomer, and also it is most unfit for learning.

It should begin with a good, clear, complete and concise explanation of a rolling release, or a link to such an explanation.

It should continue with a good, clear and concise example of how to safely install and remove a package, and maybe very few other often required operations.

After that it could continue with more involved features, like searching packages and files, updating the whole system and group management.

I'm not sure that it should contain involved configuration, as it does now in its first chapter, as this belongs to manuals, which are supposed to be references, anyway.

It should refrain from using unclear statements and unreferenced less known terminology, at least in the introductory part.

The way it is now it is a great model of how not to do it.

Why do you reject a good structure for this important page I don't know.

Why have you deleted Pacman - An Introduction where I tried to cover these drawbacks I don't know.

Why do you delete discussions where you have no good arguments to answer I don't know. Doru001 (talk) 16:19, 11 October 2015 (UTC)

The reason we're persistent on this is that a separate article basically sweeps issues under the rug. Your only argument so far against improving existing articles was to "prevent an edit war". To address this, you can always create a copy on your User page, edit it, and put it up for discussion. -- Alad (talk)
You can consider my proposition for an introduction to the main pacman page. It should be "programmer" instead of "user" in some place and other good corrections have been made later on but unfortunately after some deletions ... Doru001 (talk) 17:58, 11 October 2015 (UTC)
We have said no before and supplied arguments here, but your only activity in the discussion (as well as this one) has been merely repeating the same arguments over and over, completely ignoring our counter-arguments. You haven't convinced us there and keeping the same approach, it is very unlikely that you will succeed here.
The previous discussion on this talk page has been closed on 27 September 2015 and removed on 9 October 2015‎, which has given you sufficient time to respond and reopen it if necessary. As for your complaints on removing some content and reverting your (2 years old) revisions, please realize that ArchWiki is not your personal blog. Your opinion on "good structure" has been noted, but not accepted.
-- Lahwaacz (talk) 20:57, 11 October 2015 (UTC)