Talk:Pacman

From ArchWiki

Description of pacman internals (for new pacman programmers)

Note: The previous discussion on this subject (titled Detail missing) has been seriously derailed in the past. Please let's focus on the original topic, also presented by the current title, i.e. the description of pacman internals and its code base, targeting new pacman programmers. -- Lahwaacz (talk) 21:27, 11 October 2015 (UTC)Reply

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)
Any news about this? It would be interesting information to have. Please, can anyone reply about this? Timofonic (talk) 05:38, 23 July 2017 (UTC)Reply

pacman.log

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)Reply

Pacstrap issue

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

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)Reply

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)Reply
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)Reply
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)Reply
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.
[1] (which replaces the new section) is my proposal instead.
Kynikos (talk) 10:51, 20 August 2015 (UTC)Reply
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)Reply
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)Reply
To emphasize on the "why" again, there's:
  1. Arch_packaging_standards#Package_naming - Technical reference, somewhat cryptic
  2. System maintenance#Partial upgrades are not supported - It links to Wikipedia:Rolling release, but mostly focuses on the technical (soname bumps)
  3. 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)Reply
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)Reply
Pacman#Package updates have broken my system was partly moved to System maintenance#Revert broken updates: [2] [3] -- Alad (talk) 10:34, 23 October 2015 (UTC)Reply
Pacman#Partial upgrades are unsupported was moved to System maintenance#Partial upgrades are unsupported. [4] A warning linking to it was added in its place. [5] 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)Reply

New approach

Moved from the now closed #Pacman - An Introduction discussion. -- Alad (talk) 11:51, 23 October 2015 (UTC)Reply
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:
We should still make a clear relation to how it functions inside Arch, by linking to other articles, including a sufficient explanation.

-- Alad (talk) 03:14, 13 October 2015 (UTC)Reply

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)Reply
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)Reply
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
Note: This article describes the technical aspects of package management with pacman. If you are looking for practical tips for updating/maintaining an Arch Linux system, see System maintenance#Package tasks.
However I think this also ties into the discussion from #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)Reply

Drafts

Repository going offline

This comment is from an earlier, closed discussion -- Alad (talk) 12:19, 23 October 2015 (UTC)Reply
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)Reply
Most likely, nothing. pacman doesn't downgrade packages with -Syu - it only does so with -Syuu. Assuming by "repository" Mirrors is meant here. -- Alad (talk) 12:19, 23 October 2015 (UTC)Reply

New option for troubleshooting: use pacman-static from the AUR

This should probably be mentioned somehow. I took over maintenance of this package, it works properly, and I host both binary packages and extracted copies of the pacman-static binary, all signed by my Trusted User signing key. So it is quite safe to use.

It would help solve most issues with a non-functional pacman, as long as the system itself is more or less functional (in the sense that it boots and you can login to a root shell etc). It's sometimes suggested to use bsdtar to extract needed files directly to the filesystem by utilizing the cache, but pacman-static should work in any case where bsdtar does, and then some. -- Eschwartz (talk) 22:58, 30 May 2018 (UTC)Reply

Pacman#Manually_reinstalling_pacman and Pacman#Pacman_crashes_during_an_upgrade are basically two approaches for the "pacman is terribly broken" thing, it should be restructured to one section with subsections where you could easily mention the third option with pacman-static. -- Lahwaacz (talk) 07:59, 3 June 2018 (UTC)Reply
I just added a section for the pacman-static thing and just used subsections for that. Shout at me if it looks stupid. Maybe mentioning partial upgrades there is also out of scope.
Edit: While discussing this on IRC some people mentioned that --root is not the proper way and --sysroot should be used. I am not sure on that one since I do not really know the differences here.
-- NetSysFire (talk) 04:06, 5 April 2021 (UTC)Reply

"Unable to lock database" revisited?

Instructions in Pacman#"Failed_to_init_transaction_(unable_to_lock_database)"_error appear to be wrong for some cases. I failed to record the precise error when running sudo pacman -Syu recently however I recorded that pacman outputted an error about "flatpak remote-add" which was followed by a five-digit number, iirc and the error message ended with something about a "timeout", I waited for a couple hours but it was clear that pacman was not going to continue the update and so I exited the command with Ctrl+Z.

I logged out and back in and tried to update again. However this time I immediately got

:: Synchronizing package databases...
error: failed to update core (unable to lock database)
error: failed to update extra (unable to lock database)
error: failed to update community (unable to lock database)
error: failed to update multilab (unable to lock database)
error: failed to synchronize all databases

I did try following the instruction in the above linked section that recommends removing a db.lck file, but there was no such file to remove. I was stuck. Then I did something weird, I thought that maybe I should try to run the sudo pacman -Syu command again. To my surprise I got:

:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
multilab is up to date
:: Starting full system upgrade...
there is nothing to do

The GUI-based Package Manager similarly changed it's rhetoric from "Upgrade" this, this, "Upgrade" that etc to say "Your system is up to date".

In terms of finding a solution to this problem, a websearch on my end never suggested simply retrying the command if there is no db.lck file. It could be an intuitive thing to do. My instinct is to explicitly tell the user to try again so will do this. Archaid (talk) 17:16, 11 January 2021 (UTC)Reply

The instructions are correct. Usually if it fails it's due to permissions errors, e.g. from your "GUI-based package manager" running it with missing rights. Some of those GUIs or scripts arbitrarily delete lock files as well. Not much to go by here otherwise. -- MrX (talk) 16:01, 12 January 2021 (UTC)Reply

Add troubleshooting entry for "Dependency cycle detected"

A new entry following the current entry for "Failed to init transaction (unable to lock database)" error might be helpful. A forum search of "dependency cycle" shows this is a commonly posted issue, particularly from new users. Something like:

"Dependency cycle detected" error

Dependency cycles happen occasionally in the official repositories. In most cases, it does not affect successful upgrade.

Stuthtle (talk) 02:47, 27 September 2021 (UTC)Reply

The "dependency cycle detected" is just a warning and it is not followed by a "selection [Y/n]":
warning: dependency cycle detected:
warning: harfbuzz will be installed before its freetype2 dependency
Found this in [7].
Lahwaacz (talk) 05:49, 27 September 2021 (UTC)Reply
That is correct. The warning itself is not immediately followed by a prompt, but after the warning, pacman eventually prompts the user on whether to continue, and the prompt defaults to yes. The draft is now revised to clarify and to add possible keyring-related error. Is not the referenced forum example a package signing error and dependency cycle error? In any case, please feel free to add other language to the draft.
-Stuthtle (talk) 12:57, 27 September 2021 (UTC)Reply
The "dependency cycle detected" warning is unrelated to the keyring or package signing error: it may appear alone or the error may appear alone or they may appear together. The warning is certainly not caused by unsynced mirrors. — Lahwaacz (talk) 14:20, 27 September 2021 (UTC)Reply
I will leave this to you and others to decide how or whether to include.
Stuthtle (talk) 15:10, 27 September 2021 (UTC)Reply
Having dependency cycles in the official repositories is unavoidable (like for the mentioned harfbuzz and freetype2) and will occur regardless of mirror settings. It would also not lead to an additional prompt in this case - you get a [Y/n] prompt for any package installation or removal.
There might be a mention of cycles, but it would make better sense in the context of Creating packages or makepkg, where cycles can prevent package installation altogether. -- Alad (talk) 15:18, 27 September 2021 (UTC)Reply

More details in pacman crashes during an update

This is way overdue to be added but I am discussing this here first. We already have Pacman#Pacman crashes during an upgrade but this is only about a single, quite rare outcome.

Context: In #archlinux we have been providing manual instructions on how to recover from failed a -Syu with different severity grades with no wiki article to link to. Yesterday was the straw that broke the camels back for me since we had a user that was seemingly affected by the current nvidia troubles (https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/issues/26) and the update crashed so badly the majority of /usr/lib was just empty files and pacman.log was partially corrupted, showing just an incomplete transaction (file did not get synced to disk properly), so it couldnt be used for determining what packages were upgraded.

Very rough thing I'd add:

There is a common and not very severe breakage that happens when an update is interrupted that causes an unbootable system because the initramfs got removed and was not regenerated yet. This can easily be fixed by arch-chrooting in, since pacman will not be broken, and either -Syu'ing or pacman -S every single package that was upgraded during the transaction. However this (1) needs a regex to filter affected packages from pacman.log since you will be on a console and copy pasting will be hard (2) is in dire need of clarification how this less severe version comes to happen. I believe this is when a system crashes during the hooks and not the actual upgrade. I personally experienced this a couple of times, mostly due to e.g power cuts.

For the more severe case I will need more people chiming in who are proficient in pacman operations. Things that should be covered:

  1. How to recover basic pacman operations when libs are corrupt (maybe pacstrapping with a limited subset?)
  2. How to determine if the pacman db intact and when to reinstall all packages
  3. What outcomes happen with different interruptions at different parts at the upgrade (mostly to structure the section, sorting by most common to rare)
  4. What to do when only pacman crashes and not the whole system

NetSysFire (talk) 15:43, 27 May 2024 (UTC)Reply

Hi, I have created a small utility that will help to recover the system for mid-crashes during upgrades if one of the following conditions is met:
  • The pacman database is still working.
  • The pacman log is not corrupted.
The script is available at https://github.com/Edu4rdSHL/archlinux-pkgrecover, and it has 2 modes of recovering as stated before.
  1. Using the pacman database: the script will look for the package database in /var/lib/pacman/local and will get the list of packages that were installed/upgraded after the specified date by the user. Then it will compare the results against pacman -Qq to get the package names, and finally will reinstall the affected packages.
  2. Using the pacman log: the script will make use of the paclog utility from the pacutils package to get the list of upgraded/installed packages after the specified date by the user. Then it will compare the results against pacman -Qq to make sure that the listed packages were still installed. Note: the user can still ignore the check against -Qq (in case that the database got corrupted, for example) using the --no-db flag.
It's all I do have so far, more options can be added. i.e., for a scenario where pacman is not available inside a chroot/running system, although, that can be solved by pacman-static. Edu4rdshl (talk) 22:52, 27 May 2024 (UTC)Reply

Move parts of Additional Usage section into their specific sections

Pacman#Installing specific packages lacks local flags, but Pacman#Additional commands which are much lower down have them.

I think it would make sense to move the two relevant installation commands to the Installing Specific Packages section, i.e. # pacman -U '/path/to/package/package_name-version.pkg.tar.zst' and # pacman -U 'http://www.example.com/repo/example.pkg.tar.zst'

C0rn3j (talk) 15:56, 30 October 2024 (UTC)Reply

It does not make sense to leave the third pacman -U command alone, either move all three or none. In any case, it should be expanded with an explanation of the LocalFileSigLevel and RemoteFileSigLevel pacman.conf options. — Lahwaacz (talk) 11:22, 10 November 2024 (UTC)Reply