Difference between revisions of "Talk:Pacman"

From ArchWiki
Jump to: navigation, search
(Detail missing)
(Detail missing)
Line 71: Line 71:
:::: -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 03:04, 6 February 2013 (UTC)
:::: -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 03:04, 6 February 2013 (UTC)
:::::[[Pacman - An Introduction]] I am really short of time, so please move my paragraph there (mind the links).--[[User:Doru001|Doru001]] ([[User talk:Doru001|talk]]) 10:43, 6 February 2013 (UTC)
:::::[[Pacman - An Introduction]] I am really short of time, so please move my paragraph there (mind the links).--[[User:Doru001|Doru001]] ([[User talk:Doru001|talk]]) 10:43, 6 February 2013 (UTC)
:::::OK, I did it. If you have suggestions then please offer to help, I am really short of time.
== Pacman refuses to delete corrupted package, because it is corrupted... ==
== Pacman refuses to delete corrupted package, because it is corrupted... ==

Revision as of 10:49, 6 February 2013

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)
Yes, I fully support Detail missing and I will try to write the paragraph as an Introduction. I am happy that I am not alone on this, as I just had an argument here. Doru001 (talk) 15:06, 1 February 2013 (UTC)
Well, the improvement is here: Introduction. The news statement does not look right. Where are those news about the introduction of systemd and the need to copy a directory of glibc?--Doru001 (talk) 16:38, 3 February 2013 (UTC)
I have reverted these changes. There were a couple of problems with your contribution:
  1. You overwrote the Upgrading packages section without explanation.
  2. You over-used personal pronouns. Please read Help:Style.
  3. You point to the Wiki News page as a source for package / update advisories, rather than https://www.archlinux.org/news/.
I appreciate your effort, but I think this contribution needs improvement before being included at the beginning of one of ArchWiki's most prominent articles. I do agree that a high-level overview like this would be helpful. I would suggest that you avoid using any actual pacman code / commands in this section to avoid duplicating content in the rest of the article. A detailed overview in plain English would be most beneficial.
I have moved your contribution below:
-- pointone (talk) 18:07, 3 February 2013 (UTC)
== Introduction ==

Packages in ''arch repositories'' are constantly upgraded. When a package is upgraded, its old version is removed from the repository. There are no major arch releases. Each package is upgraded as new versions become available from upstream sources. The repository is always coherent. (The packages in the repository always have compatible versions.) This type of repository is called a '''rolling archive'''. Before packages are upgraded in the '''core''', '''extra''' and '''community''' repositories, they are tested in the '''testing''' repository, to ensure that the distribution is stable. 

{{ic|pacman}} saves to disk a list of packages available in the repository. This list is not automatically updated (refreshed). You can refresh the list using {{ic|pacman -Sy}}. {{ic|pacman -Syy}} refreshes the list even if it appears to be up to date. ({{ic|pacman -Syy}} is a good idea when you change the repository mirror used by {{ic|pacman}}. Mirrors can be out of sync and the package list from the old mirror may not correspond to the package list of the new mirror, even though the dates of the lists may suggest that they do.) 

{{ic|pacman -S ''mypackage''}} installs {{ic|''mypackage''}} and all its dependencies. If {{ic|''mypackage''}} has been upgraded since the last refresh of the package list, then the required version of {{ic|''mypackage''}} will not be found in the repository and {{ic|pacman -S ''mypackage''}} fails with a message. {{ic|''mypackage''}}'s dependencies are listed in the '''Depends On''' entry of {{ic|''mypackage''}}'s ''metainformation''. ({{ic|''mypackage''}}'s ''metainformation'' can be listed with {{ic|pacman -Si ''mypackage''}} for packages in the package list and with {{ic|pacman -Qi ''mypackage''}} for installed packages). If {{ic|''mypackage''}} or its dependencies are already installed, they are upgraded to the version in the package list. If {{ic|pacman -S ''mypackage''}} finds any conflicts (installed packages which are listed in the '''Conflicts With''' entry of the {{ic|''mypackage''}}'s ''metainformation'') then it fails with a message. {{Warning|However, {{ic|pacman -S ''mypackage''}} does not check for broken dependencies which may appear from the possible upgrade of {{ic|''mypackage''}} or one of its dependencies. It is possible that an already installed package which depends on an upgraded package is unable to function with the new version of the upgraded package. This can happen if you have refreshed your package list but you have not upgraded all installed packges and it could break your system.}} 

The solution is to never run {{ic|pacman -Sy}}, which could be followed by {{ic|pacman -S ''mypackage''}}, but to always run {{ic|pacman -Syu}}, which upgrades all packages after the refresh of the package list. This ensures that when you run {{ic|pacman -S ''mypackage''}} all packages installed on the system have compatible versions. 

When you run {{ic|pacman -Syu}} there is a small chance that you will have to perform corrections on your system in order to have it running as you like. Important corrections are advertised here: [[Wiki News]]. They are very rare (three in 2012). However, you may like to run {{ic|pacman -Syu}} only when you have time to perform corrections and not when you rely on your system. It is a good idea to run {{ic|pacman -Syu}} often in order to minimize the difficulty of adjustment, whenever it arises. 

{{ic|pacman -R ''mypackage''}} removes {{ic|''mypackage''}}. If other packages depend on {{ic|''mypackage''}}, then it fails with a message. In order to remove them too, run {{ic|pacman -Rc ''mypackage''}}. {{Warning|You should carefully check the list of packages to be removed before you remove them. Otherwise, you may remove packages required by your system to function.}} {{ic|pacman -R ''mypackage''}} does not remove {{ic|''mypackage''}}'s dependencies which have been installed as dependencies (not explicitly, '''Install Reason''' in {{ic|''mypackage''}}'s ''metainformation'') and are not required by other packages. In order to do that, you run {{ic|pacman -Rs ''mypackage''}}. The complete command would be {{ic|pacman -Rcs ''mypackage''}}. 

{{Note|{{ic|pacman}} always lists packages to be installed or removed and asks for permission before it takes action. To inhibit any action, use {{ic|-p}}.}} 

As you can see, {{ic|pacman}} operates at a lower level compared to {{ic|yum}} and {{ic|apt}}. This requires more attention from you in using it, but it also empowers you with better control over your system. 

For those who have used other linux distributions before, there is a helpful [[Pacman Rosetta]].
  1. I know that I am not the first archlinux beginner user who has trouble learning how to use pacman. The forums hold a good set of discussions on this topic, even experienced users state that they did not know about the dangers of pacman -Sy; pacman -S package. In order for this situation to arise there must be a number of conditions fulfilled:
    1. elliptic and unclear manual. the first example that comes to my mind:
      Recursively reinstall all dependencies of the targets. This forces upgrades or
      reinstalls of all dependencies without requiring explicit version requirements. This
      is most useful in combination with the --needed flag, which will induce a deep
      dependency upgrade without any unnecessary reinstalls.

      Why does this exist, when -S and -U already include it? I am missing something. Something that should have been obvious, but it is not.
    2. elliptic and unclear pacman page. It seems that we have an agreement on this. However, I may be not the first rejected contributor.
      1. The Introduction must repeat the content. This is the point, to provide a friendly introduction to the content. The content must elaborate on evey point explained in the introduction.
      2. The manual and the pacman wiki, short and elliptic as they are, succeed to use inconsistent terminology for basic unexplained notions like "rolling archive" and "synchronizing repository databases". I believe that, contrary to the comment, I provide an explanation.
      3. Last but not least, I thought that this wiki is a place for mutual cooperation and not for mutual destruction. The comments refer to easy to fix issues, and I believe that preventing access of beginners to this introduction for the before mentioned problems is an exaggerated response.
  2. Yes, I did overuse the personal pronouns. In most cases the text improved when I changed this. However, in some cases, the text became less clear. There are two important agents in this story: the system and the user. When you take out the personal pronouns it becomes less clear who is the agent to which the text refers. When I say that the package list can be refreshed the question arises: by whom? It is vitally important for the beginner user to know immediately that only him can do that. I did my best.
  3. Thank you for the link to news. I remembered it overnight but still I appreciate the assistance.
  4. I completely oppose the proposition to remove all commands from the introduction. As a beginner, I know very well what I wanted to find on this page and I did not. If the commands are missing, visual memory will be unable to link the information provided in plain English to important symbols to remember and the page will become practically of no use to the newcomer. Please do not delete the paragraph again for this reason. Accept a wider based discussion with beginner users before a decision is taken. The rest of the page has many issues to present, like for example what is that -S --recursive option doing. There are at least ten such unclear options in the manual.

I am not going to start an editing war on this page. I thought that I should help beginners like me to easier enter this distribution of linux, which is based on a very effective philosophy. However, in case that I am not supported by any other user in my endeavour, you can delete everything you like. Doru001 (talk) 11:39, 4 February 2013 (UTC)

I've looked at the revised introduction, and think Doru001 is on the right path.

Some suggestions : Use subsections to make the text more readable : overview databases installing/upgrading removing

In the installing/upgrading and removing sections add links to relevant parts with more detail further on the page. example: the installing/upgrading subsection could have something like : Partial upgrades are UNSUPPORTED, see https://wiki.archlinux.org/index.php/Pacman#Partial_upgrades_are_unsupported for details.

About pacman -Sy : Mention it only in the databases subsection with its 2 use-cases (repo added, switching mirrors). Make clear it's only a good choice for those cases, and a bad choice for all others. (Lone_Wolf (talk) 13:13, 4 February 2013 (UTC))

Thank you very much for your support. Your suggestions are very good (I suppose that you mean -Syy, no -Sy). I am short on time, so anybody is invited to put them into the text.
Hi, Doru001 what you suggest is very usuful. But the way you push out the changes is wrong. Your edit is a major one on one of the most important ArchWiki page. So discussion on talk page is needed. Here is my suggestion:
Since most of your info is already exist in this page and it looks like some kind of tutorials. You can create a new Classroom page such as How to use pacman.
-- Fengchao (talk) 03:04, 6 February 2013 (UTC)
Pacman - An Introduction I am really short of time, so please move my paragraph there (mind the links).--Doru001 (talk) 10:43, 6 February 2013 (UTC)
OK, I did it. If you have suggestions then please offer to help, I am really short of time.

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.

# cacheclean.py 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)

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)

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)
Close old topic. There is another attempt to document upgrade process in a different way. See #Detail missing. -- Fengchao (talk) 07:42, 4 February 2013 (UTC)

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)

Is the procedure in the last Q&A correct?

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." 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?--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. -- pointone 20:13, 31 March 2012 (EDT)
I added some clarification to that step of the procedure - Gcool 11:09, 27 April 2012 (UTC)