Description of pacman internals (for new pacman programmers)
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 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
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)
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)
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: https://bbs.archlinux.org/viewtopic.php?id=162216
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)
- 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)
- To emphasize on the "why" again, there's:
- Arch_packaging_standards#Package_naming - Technical reference, somewhat cryptic
- System maintenance#Partial upgrades are not supported - It links to Wikipedia:Rolling release, but mostly focuses on the technical (soname bumps)
- Frequently_asked_questions#Why_is_there_only_a_single_version_of_each_shared_library_in_the_official_repositories.3F - More explicit, but does this really belong in the FAQ? For now, I've linked it from the warning in Pacman#Installing packages anyway.
- I also agree that the actual Official repositories could be expanded. The brief mention in Arch_Linux#Modernity is enough for the scope of that article. -- Alad (talk) 12:06, 23 October 2015 (UTC)
- To emphasize on the "why" again, there's:
- Enhance system stability was cleaned and merged to System maintenance. I believe latter is the article where the recommended practices should be described. -- Alad (talk) 09:45, 23 October 2015 (UTC)
- Pacman#Package updates have broken my system was partly moved to System maintenance#Revert broken updates:   -- Alad (talk) 10:34, 23 October 2015 (UTC)
- Pacman#Partial upgrades are unsupported was moved to System maintenance#Partial upgrades are unsupported.  A warning linking to it was added in its place.  The Partial upgrade redirect(s) were updated, but awaiting further structure changes, only generally to System maintenance. -- Alad (talk) 10:12, 23 October 2015 (UTC)
- Right now, package management on the wiki is fragmented and duplicated, and it's clear that creating another page won't help in solving this. As pointed out in #Don't rush updates, we have System maintenance, Enhance system stability, this article, Official repositories, Arch Linux, Arch packaging standards, ... not even mentioning specialist articles, the FAQ linked from the Main page or General troubleshooting. To make things worse, these articles are in different categories.
- A few suggestions:
- Pacman, while a prominent feature of Arch, is not a distribution-specific tool.  As such, this page should limit it's scope to 1. providing an introduction to basic commands, 2. refer and introduce to pacman(8) and pacman.conf(5), 3. clarify on the inner workings, per #Description of pacman internals (for new pacman programmers).
- We should still make a clear relation to how it functions inside Arch, by linking to other articles, including a sufficient explanation.
- Configuration should indeed be expanded upon after basic usage, again keeping the manuals and other material in mind.
- I would suggest cleaning and merging the System maintenance and Enhance system stability articles, moving the most common Q/A to - or linking it in - the FAQ or similar article. Having a central location for "Recommended practices", as pointed out in #Don't rush updates, is key here. See also ArchWiki:Requests#FAQ.
- Specialist cases should be moved to subpages of Pacman, for example Pacman/Tips and tricks.
- Small update: pacman now has 4 subpages, Pacman/Tips and tricks (merge of pacman tips and Improve pacman performance), Pacman/Pacnew and Pacsave (from Pacnew and Pacsave files), Pacman/Rosetta (from Pacman Rosetta) and Pacman/Package signing (from pacman-key).
- Haven't moved Downgrade packages yet, as it's equally related to Official repositories. -- Alad (talk) 16:39, 16 October 2015 (UTC)
- You did not answer any of my arguments. You could say "yes, it is true that many people come on this page to understand pacman and that pacman's functionality can't be understood without understanding rolling repositories and that there is no explanation or at least a link to an explanation of this, but I don't care." I don't argue here in favor of a new page. Doru001 (talk) 19:49, 13 October 2015 (UTC)
- I have actually been struggling with this same issue myself. Based on the number of problems reported on the mailing and list and forums that can be summarized as "User does not understand rolling release and good pacman practices," I think there is a pretty clear need for more directed documentation that increases the chance of new users learning the essential parts of maintaining an Arch system. However, I'm not convinced that pacman is the right article for this information. Despite its importance, pacman is just another program distributed with Arch Linux and this article describes its technical ins and outs. You don't see Git including a discussion of the DVCS philosophy or Ruby including a treatise on object-oriented design, despite the fact that these are (arguably) essential skills for properly using such software.
- I think that the simplest solution would be to add a note right after the introductory paragraph, along the lines of #Don't rush updates, in that we need a good unified location for such information that the note could link to. Frankly, the System maintenance article is just as lacking for new users. Silverhammermba (talk) 15:55, 15 October 2015 (UTC) However I think this also ties into the discussion from
- I've made a draft to outline the merging of the aforementioned pages: User:Lahwaacz/Recommended package management practices. There is still long way to go, but I think it already contains everything relevant from System maintenance and Enhance system stability. -- Lahwaacz (talk) 18:33, 17 October 2015 (UTC)
- My (very similar) draft User:Silverhammermba/Recommended package management practices. I'm trying to take a different approach to the article, but right now it's not very significant. Perhaps they will diverge more as we expand them. Silverhammermba (talk) 15:15, 20 October 2015 (UTC)
Repository going offline
- what happens when your repository goes off line and you fallback on a repository not yet updated? I still don't know, I only use one repository at a time! Doru001 (talk) 14:47, 15 October 2015 (UTC)