Difference between revisions of "Talk:Pacman"

From ArchWiki
Jump to: navigation, search
(No RTFM or personal opinions: rm closed discussion)
m (Proposal to add another section referencing the use of nested statements: sign)
 
(254 intermediate revisions by 20 users not shown)
Line 1: Line 1:
== Detail missing ==
+
== Description of pacman internals (for new pacman programmers) ==
 +
 
 +
{{META Box Blue|Moderation note:|2=
 +
The previous discussion on this subject (titled [https://wiki.archlinux.org/index.php?title=Talk:Pacman&oldid=252437#Detail_missing 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. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:27, 11 October 2015 (UTC)
 +
}}
 +
 
 
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.
 
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.
  
Line 6: Line 11:
 
::[http://allanmcrae.com/2012/02/the-great-pacman-bug-hunt-of-2012/ Some more, pretty low level, info], also from Allan's blog. -- [[User:Karol|Karol]] 13:24, 11 February 2012 (EST)
 
::[http://allanmcrae.com/2012/02/the-great-pacman-bug-hunt-of-2012/ Some more, pretty low level, info], also from Allan's blog. -- [[User:Karol|Karol]] 13:24, 11 February 2012 (EST)
  
== Pacman refuses to delete corrupted package, because it is corrupted... ==
+
== pacman.log ==
  
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. -- [[User:Misc|Misc]] 20:17, 17 April 2010 (EDT)
+
There are (as of this writing) two places on this page which say that <code>pacman</code>'s output is logged to <code>/var/log/pacman.log</code>. Obviously in the strictest sense this is false, as can easily be seen by anybody who's glanced at this file and at <code>pacman</code>'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'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. - [[User:KitchM|KitchM]] 23:01, 18 April 2010 (EDT)
+
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:
  
== proposed addition to package cache cleaning... ==
+
* Package installation complete
 +
* Most but not all of the per-package notices <code>pacman</code> prints.
  
''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?''
+
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 <code>pacman -Qi</code> or <code>expac</code>. 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 <code>pacman</code> output by assuming it'd be in the log.
  
Alternatively, the [[https://aur.archlinux.org/packages.php?ID=37572 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.
+
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". [[User:DHouck|DHouck]] ([[User talk:DHouck|talk]]) 08:14, 22 February 2014 (UTC)
  
# cacheclean.py 2
+
== Exit codes ==
  
- [[User:graysky|graysky]] 16:18, 28 May 2010 (EDT)
+
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 {{ic|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?
  
:Disagree; I think we should keep these kinds of ''unsupported'' tools, etc. in [[pacman Tips]]. -- [[User:Pointone|pointone]] 18:07, 2 September 2010 (EDT)
+
-- Andy Crowd 08:00, 9 January 2015 (UTC)
::I see it has been added at the end of [[Pacman#Additional_commands]]. Maybe we should mention {{ic|paccache}} from {{ic|pacman-contrib}} instead? -- [[User:Karol|Karol]] 13:02, 10 February 2012 (EST)
+
  
== Troubleshooting: manually reinstall pacman ==
+
:This is something that belongs in the manual. I'd suggest [https://bugs.archlinux.org/index.php?project=3&do=index&switch=1 filing a bug]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:20, 20 August 2015 (UTC)
  
{{FAQ
+
== Pacstrap issue ==
|question=Pacman searches very slow for updatable packages.
+
 
|answer=This is probably due to package list fragmentation. To fix this problem use 'pacman -Syy'
+
:Moved from [[Beginners' guide]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:11, 20 February 2015 (UTC)
}}
+
 
 +
I don't know how many others are experiencing trouble when issuing the {{ic|pacstrap -i /mnt base base-devel}} command but I got a series of {{ic|GPGME ERROR: no data}} errors. This post helped: https://bbs.archlinux.org/viewtopic.php?id=162216
 +
You need to run: {{ic|rm -R /mnt/var/lib/pacman/sync}}
 +
and try again the pacstrap command. {{Unsigned|11 February 2015|Sudoku}}
 +
 
 +
== Don't rush updates ==
 +
 
 +
[https://wiki.archlinux.org/index.php?title=Pacman&diff=391408&oldid=390815 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? — [[User:Kynikos|Kynikos]] ([[User talk: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. [[User:Herodotus|Herodotus]] ([[User talk: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]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 03:30, 19 August 2015 (UTC)
 +
 
 +
:::How about [https://wiki.archlinux.org/index.php?title=Pacman&diff=391745&oldid=391589 this]. I'm not an expert so I mostly borrowed stuff from the deleted section and [[Enhance_system_stability#Arch_Specific_Tips_2]]. [[User:Herodotus|Herodotus]] ([[User talk: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.
 +
::::[https://wiki.archlinux.org/index.php?title=Pacman&diff=392814&oldid=391745] (which replaces the new section) is my proposal instead.
 +
::::— [[User:Kynikos|Kynikos]] ([[User talk: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. -- [[User:Alad|Alad]] ([[User talk: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 [https://wiki.archlinux.org/index.php?title=Talk:Pacman_-_An_Introduction&oldid=392978#Rolling_release_terms 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.
 +
::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:06, 23 October 2015 (UTC)
 +
 
 +
:::::::[[Enhance system stability]] was cleaned and merged to [[System maintenance]]. I believe latter is the article where the recommended practices should be described. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:45, 23 October 2015 (UTC)
 +
:::::::[[Pacman#Package updates have broken my system]] was partly moved to [[System maintenance#Revert broken updates]]: [https://wiki.archlinux.org/index.php?title=System_maintenance&diff=406302&oldid=406294] [https://wiki.archlinux.org/index.php?title=Pacman&diff=406283&oldid=406281] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:34, 23 October 2015 (UTC)
 +
:::::::[[Pacman#Partial upgrades are unsupported]] was moved to [[System maintenance#Partial upgrades are unsupported]]. [https://wiki.archlinux.org/index.php?title=System_maintenance&diff=406285&oldid=406270] A warning linking to it was added in its place. [https://wiki.archlinux.org/index.php?title=Pacman&diff=406290&oldid=406287] The [[Partial upgrade]] redirect(s) were updated, but awaiting further structure changes, only generally to [[System maintenance]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:12, 23 October 2015 (UTC)
 +
 
 +
=== New approach ===
 +
 
 +
::''Moved from the now closed [[#Pacman - An Introduction]] discussion. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:51, 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. [https://bbs.archlinux.org/viewtopic.php?pid=828254#p828254] As such, this page should limit it's scope to 1. providing an introduction to basic commands, 2. refer and introduce to [https://www.archlinux.org/pacman/pacman.8.html pacman(8)] and [https://www.archlinux.org/pacman/pacman.conf.5.html 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]].
 +
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 03:14, 13 October 2015 (UTC)
 +
 
 +
::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]]. -- [[User:Alad|Alad]] ([[User talk: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. [[User:Doru001|Doru001]] ([[User talk: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 {{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. [[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 15:55, 15 October 2015 (UTC)
 +
 
 +
=== Drafts ===
 +
 
 +
* 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]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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. [[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 15:15, 20 October 2015 (UTC)
 +
 
 +
=== Repository going offline ===
 +
 
 +
::''This comment is from an earlier, closed discussion -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:19, 23 October 2015 (UTC)''
 +
: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! [[User:Doru001|Doru001]] ([[User talk:Doru001|talk]]) 14:47, 15 October 2015 (UTC)
 +
::Most likely, nothing. pacman doesn't downgrade packages with {{ic|-Syu}} - it only does so with {{ic|-Syuu}}. Assuming by "repository" [[Mirrors]] is meant here. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:19, 23 October 2015 (UTC)
  
== testdb ==
+
== Proposal to add another section referencing the use of nested statements ==
 +
Earlier I proposed an addition to the [[Pacman#Removing_packages]] section:
 +
<blockquote>To remove a package using pacman's query operation:
 +
<code># pacman -R $(pacman -Qs | grep "package_name")</code></blockquote>
  
IMO it should be added to this page. You can get text from [https://bbs.archlinux.org/viewtopic.php?pid=320958]. --[[User:Beroal|Beroal]] 13:13, 8 November 2010 (EST)
+
User [[User:Kynikos]] removed the edition because, ''"this is too specific for this article, please propose it in Tips & Tricks"''
  
 +
Ok. I understand there are style guidelines for what should and should not be included on the main page of a node. Let me say first, this style of comment is included above in the [[Pacman#Installing_specific_packages]] section.
  
== Post upgrade tasks ==
+
More importantly, the impetus to add the change was because I tried to remove a group of packages, read the instructions, it didn't work, searched the forums and found my old post from a year ago. LOL. I've done it again. I forgot how to use Pacman, and this use case (where the simple -R flag doesn't work) happens for me once a year (read, I will forget again). I still use CentOS and Debian in other projects, and I just simply forgot the ArchWay. 
  
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)
+
My point is I think the wiki should permit changes which highlight, give examples or simply reference when Arch, as a distro of Linux, does something in a way the other major distros do not (a "get a clue" for more casual users). My simple solution is to permit changes that communicate by example to the reader--in my case--that pacman sometimes requires a different (nested) syntax.
  
PD. I've to add a space between brackets ( [ [ and ] ] expressions) to avoid generate links
+
Alternatively, a new section to the pacman page could be added referencing the rich possibilities of using pacman in this manner, <tt>pacman ... $(pacman ... | grep ... )</tt>. I don't see this as a "tip" or "trick" but as a significant difference from other distros (and I'm sure for good reason--which is why I value the Archlinux distro very much).
:Fixed with <nowiki><nowiki></nowiki> tags. -- [[User:Karol|Karol]] 10:20, 15 May 2011 (EDT)
+
  
  !#/bin/sh
+
{{unsigned|01:07, 11 July 2016‎|Xtian}}
  echo "* Looking recursively for *.pacnew en /etc ..."
+
  pacnew=$(find /etc -type f -name "*.pacnew" 2>/dev/null)
+
  MELD=""
+
  for config in $pacnew; do
+
    # Merge with meld
+
    sudo meld ${config%\.*} $config
+
    MELD="1"
+
  done
+
  if <nowiki>[[ "$MELD" != "" ]]</nowiki>; then
+
    echo "  Recursively delete /etc/*.pacnew? (y/N)"
+
    read CONFIRM
+
    if <nowiki>[[ "$CONFIRM" == "y" ]]</nowiki> ; then
+
      echo "* Recursively deleting *.pacnew from /etc/"
+
      find /etc/ -name "*.pacnew" -exec sudo rm {} \;
+
    fi
+
  else
+
    echo "  Not found"
+
  fi
+
  HUERFANOS="`pacman -Qdtq`"
+
  if [ "$HUERFANOS" != "" ]; then
+
        echo "* Deleting orphan packages..."
+
        sudo pacman -Rsn $HUERFANOS
+
  fi
+
  echo "* Deleting packets' cache..."
+
  sudo pacman -Sc
+
  echo "* Done."
+
  echo ""
+
  
--[[User:RkG|RkG]] 08:53, 15 May 2011 (EDT)
+
:As the main point seems to be how this is unexpected for users from other distributions, this belongs in [[Pacman/Rosetta]] if anywhere. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:50, 11 July 2016 (UTC)
:<tt>pacman -Sc</tt>? 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 ([[User:RkG|RkG]]), not to the pacman article. -- [[User:Karol|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 --[[User:RkG|RkG]] 02:51, 16 May 2011 (EDT)
+
  
== version comparision ==
+
:At least the command should be <code># pacman -R $(pacman -Qs'''q''' | grep "package_name")</code>, otherwise it does not work at all. Even then, it might produce unexpected false positives - that's why pacman does not support ''remove by regex'' operation. See [http://askubuntu.com/questions/210976/apt-get-remove-with-wildcard-removed-way-more-than-expected-why] for the consequences.
 +
:As for your rants, this "tip" or "trick" is not really about pacman, but plain shell usage (i.e. chaining multiple commands together), applicable in other distros as well. That's what is too specific about it.
 +
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:00, 11 July 2016 (UTC)
  
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.
+
::The reasons for my undo weren't about style, but:
 +
::# this article is limited to pacman-specific features, not shell command extensions of it: you can't find any grepping, awking, piping, substituting, etc here, all that belongs to [[Pacman/Tips and tricks]], which is in fact where I pointed the OP to;
 +
::# the command was only introduced by "To remove a package using paceman's [''sic''] query operation", which is completely missing the reasons why one would need to use it, hence confusing readers who would compare it to the plain -R commands; in theory packages should be related by a group or dependencies, not just name affinities, and for example the -Rs and -Rc options are already there for this kind of cleanups.
 +
::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:34, 11 July 2016 (UTC)
  
Short: I found fb9 is really less than fb10.
+
::: The reason I added this was because the normal -R flag didn't work in my case. I think you're right to say shell command extensions by and large don't belong here. My point is to suggest it could be good style for the WIKI to sprinkle a few good examples of useful shell command extension combinations or pacman idioms in the main page, and point to "Tips and Tricks". The reader may be inclined to recognize in which direction they should look when the pacman doesn't work as expected.  A different rule of style would permit what otherwise does not fit the strict boundary you clearly outline, pacman-specific features. A style change would say getting users to think in the ArchWay using shell commands could benefit by more examples. The pacman Man Page is pacman-specific. I should hope the Wiki would include user's best practices and useful examples.  
  
It took me a while to find, so I place the links here: [http://code.toofishes.net/pacman/doc/version_8c_source.html version.c source] and [http://code.toofishes.net/pacman/doc/group__alpm__api__packages.html#gaa02179706f44681dd80c75f7fb8017b2 alpm_pkg_vercmp description]. This is what is used.
+
::: The comment for my original change, "(Was having trouble removing haskell package...), referenced my post in forums. I installed haskell-pandoc to get a library to support iPython's export to PDF feature. At that time I needed to create this documentation and I didn't care that the dependencies for haskell-pandoc totaled 1.6G. Only later, when I went to uninstall haskell, I couldn't figure out which "thread to pull" because there is no "haskell" package.
It tries to split the version in only-numeric and only-alpha parts. --[[User:JonnyJD|JonnyJD]] 13:58, 1 March 2012 (EST)
+
  
== Is the procedure in the last Q&A correct? ==
+
::: That's the reason and reasoning. If this makes sense to you, then great. If not, Ok too.
  
My Arch did not boot after a upgrade finaly I got it working again by following the procedure which is given for the question "After updating my system, I get a "unable to find root device" error after rebooting and my system will no longer boot."
+
::: [[User:Xtian|Xtian]] ([[User talk:Xtian|talk]]) 00:37, 12 July 2016 (UTC)
It did not work after I did exactely what is writen there. Specifically the "mkinitcpio -p linux" failed it complaint that it did not found the linux image. After I unmounted everything and started again without "# mount /dev/sdx boot/ (your /boot partition)" it indeed worked.
+
Could someone who knows better than I check whether the mount command i question is necessary?--[[User:Vorwaerts|Vorwaerts]] 16:36, 31 March 2012 (EDT)
+
:It is indeed necessary if you have a separate /boot partition. It sounds like you do not, and you instead mounted another partition on top of your /boot directory. The instructions could perhaps be clarified, or, better yet, link to the [[chroot]] article. -- [[User:Pointone|pointone]] 20:13, 31 March 2012 (EDT)
+
  
:I added some clarification to that step of the procedure - [[User:Gcool|Gcool]] 11:09, 27 April 2012 (UTC)
+
::::First, I don't think it's such a nice little harmless command as you describe, since it would have to be accompanied by a big red warning about the unwanted consequences (see my previous post).
 +
::::Second, since we're arguing to not describe your command on '''this page''' and you are still arguing to describe it on '''the wiki''', I would like to finally make you aware of the [[pacman/Tips and tricks]] subpage (which Kynikos was mentioning from the start, apparently without success). The subpage is mentioned multiple times on the [[pacman]] page, including a box of related articles in the top right corner. I'm sure everybody would like to have the one trick they needed recently in the first paragraph of the main [[pacman]] page, but obviously that's not possible. The tips and tricks cannot be described on the main [[pacman]] page, because the "Tips and tricks" subpage is almost as long as the main page.
 +
::::Finally, the [[pacman/Tips and tricks]] subpage contains better&trade; tips for efficient usage of pacman, that would have been applicable in your case: [[pacman/Tips and tricks#Listing packages]] for listing biggest or newly installed packages and [[pacman/Tips and tricks#Removing unused packages (orphans)]] for removing orphans.
 +
::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 05:56, 12 July 2016 (UTC)

Latest revision as of 05:56, 12 July 2016

Description of pacman internals (for new pacman programmers)

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

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)

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)

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: 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)
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.
[1] (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)
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)
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: [2] [3] -- Alad (talk) 10:34, 23 October 2015 (UTC)
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)

New approach

Moved from the now closed #Pacman - An Introduction discussion. -- Alad (talk) 11:51, 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:
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)

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

Drafts

Repository going offline

This comment is from an earlier, closed discussion -- Alad (talk) 12:19, 23 October 2015 (UTC)
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)
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)

Proposal to add another section referencing the use of nested statements

Earlier I proposed an addition to the Pacman#Removing_packages section:

To remove a package using pacman's query operation: # pacman -R $(pacman -Qs | grep "package_name")

User User:Kynikos removed the edition because, "this is too specific for this article, please propose it in Tips & Tricks"

Ok. I understand there are style guidelines for what should and should not be included on the main page of a node. Let me say first, this style of comment is included above in the Pacman#Installing_specific_packages section.

More importantly, the impetus to add the change was because I tried to remove a group of packages, read the instructions, it didn't work, searched the forums and found my old post from a year ago. LOL. I've done it again. I forgot how to use Pacman, and this use case (where the simple -R flag doesn't work) happens for me once a year (read, I will forget again). I still use CentOS and Debian in other projects, and I just simply forgot the ArchWay.

My point is I think the wiki should permit changes which highlight, give examples or simply reference when Arch, as a distro of Linux, does something in a way the other major distros do not (a "get a clue" for more casual users). My simple solution is to permit changes that communicate by example to the reader--in my case--that pacman sometimes requires a different (nested) syntax.

Alternatively, a new section to the pacman page could be added referencing the rich possibilities of using pacman in this manner, pacman ... $(pacman ... | grep ... ). I don't see this as a "tip" or "trick" but as a significant difference from other distros (and I'm sure for good reason--which is why I value the Archlinux distro very much).

—This unsigned comment is by Xtian (talk) 01:07, 11 July 2016‎. Please sign your posts with ~~~~!

As the main point seems to be how this is unexpected for users from other distributions, this belongs in Pacman/Rosetta if anywhere. -- Alad (talk) 06:50, 11 July 2016 (UTC)
At least the command should be # pacman -R $(pacman -Qsq | grep "package_name"), otherwise it does not work at all. Even then, it might produce unexpected false positives - that's why pacman does not support remove by regex operation. See [7] for the consequences.
As for your rants, this "tip" or "trick" is not really about pacman, but plain shell usage (i.e. chaining multiple commands together), applicable in other distros as well. That's what is too specific about it.
-- Lahwaacz (talk) 07:00, 11 July 2016 (UTC)
The reasons for my undo weren't about style, but:
  1. this article is limited to pacman-specific features, not shell command extensions of it: you can't find any grepping, awking, piping, substituting, etc here, all that belongs to Pacman/Tips and tricks, which is in fact where I pointed the OP to;
  2. the command was only introduced by "To remove a package using paceman's [sic] query operation", which is completely missing the reasons why one would need to use it, hence confusing readers who would compare it to the plain -R commands; in theory packages should be related by a group or dependencies, not just name affinities, and for example the -Rs and -Rc options are already there for this kind of cleanups.
— Kynikos (talk) 11:34, 11 July 2016 (UTC)
The reason I added this was because the normal -R flag didn't work in my case. I think you're right to say shell command extensions by and large don't belong here. My point is to suggest it could be good style for the WIKI to sprinkle a few good examples of useful shell command extension combinations or pacman idioms in the main page, and point to "Tips and Tricks". The reader may be inclined to recognize in which direction they should look when the pacman doesn't work as expected. A different rule of style would permit what otherwise does not fit the strict boundary you clearly outline, pacman-specific features. A style change would say getting users to think in the ArchWay using shell commands could benefit by more examples. The pacman Man Page is pacman-specific. I should hope the Wiki would include user's best practices and useful examples.
The comment for my original change, "(Was having trouble removing haskell package...), referenced my post in forums. I installed haskell-pandoc to get a library to support iPython's export to PDF feature. At that time I needed to create this documentation and I didn't care that the dependencies for haskell-pandoc totaled 1.6G. Only later, when I went to uninstall haskell, I couldn't figure out which "thread to pull" because there is no "haskell" package.
That's the reason and reasoning. If this makes sense to you, then great. If not, Ok too.
Xtian (talk) 00:37, 12 July 2016 (UTC)
First, I don't think it's such a nice little harmless command as you describe, since it would have to be accompanied by a big red warning about the unwanted consequences (see my previous post).
Second, since we're arguing to not describe your command on this page and you are still arguing to describe it on the wiki, I would like to finally make you aware of the pacman/Tips and tricks subpage (which Kynikos was mentioning from the start, apparently without success). The subpage is mentioned multiple times on the pacman page, including a box of related articles in the top right corner. I'm sure everybody would like to have the one trick they needed recently in the first paragraph of the main pacman page, but obviously that's not possible. The tips and tricks cannot be described on the main pacman page, because the "Tips and tricks" subpage is almost as long as the main page.
Finally, the pacman/Tips and tricks subpage contains better™ tips for efficient usage of pacman, that would have been applicable in your case: pacman/Tips and tricks#Listing packages for listing biggest or newly installed packages and pacman/Tips and tricks#Removing unused packages (orphans) for removing orphans.
-- Lahwaacz (talk) 05:56, 12 July 2016 (UTC)