Talk:Pacman/Tips and tricks

From ArchWiki
Jump to navigation Jump to search

pacman-optimize on SSD

[Moved from Talk:Improve pacman performance -- Alad (talk) 05:05, 16 October 2015 (UTC)]

pacman-optimize only tries to reduce fragmentation of the files right? If that is the case perhaps we should include a note that this probably won't help much on an SSD. —This unsigned comment is by F4hy (talk) 18:27, 29 March 2013‎. Please sign your posts with ~~~~!

pacman-optimize was removed in 2016-10-01 from pacman as it does nothing useful, according to its developer[1]. So, I guess this topic is done. -- Josephgbr (talk) 19:22, 23 February 2020 (UTC)


[Moved from Talk:Improve pacman performance -- Alad (talk) 05:05, 16 October 2015 (UTC)]

Looks like the systemd-timer-pacman-optimize-git package is no longer maintained. [2]

Should the wiki no longer recommend this package? -- I'm guessing it shouldn't.

Also, is pacman-optimize less important than in the past? -- I am genuinely unsure about this.

--Matthew02 (talk) 05:40, 2 March 2015 (UTC)

The maintenance of systemd-timer-pacman-optimize-gitAUR has nothing to do with that of pacman itself, it is packaged separately and even in the AUR. Anyway, I'd keep the section until pacman-optimize is removed from pacman.
The reasons why it is not very important nowadays are improvements in pacman itself (mentioned in the ML post linked above), increased speeds of HDDs and the advent of SSDs.
-- Lahwaacz (talk) 22:18, 2 March 2015 (UTC)
pacman-optimize was remove from pacman in 2016 (see commit), and mentions to this tool were removed from this wiki page in 2018 (See Special:Diff/524293). So, I guess this topic is done.
-- Josephgbr (talk) 19:30, 23 February 2020 (UTC)

Leading slash

Pacman/Tips_and_tricks#aria2 doesn't work without leading slash, i.e. -d / turning file names to //var/cache/.... The article mentions this, but it doesn't mention why. -- Alad (talk) 05:28, 16 October 2015 (UTC)

You would have to go way back to track this. It seems to have worked without -d / even in 2006: [3], [4]. I guess that simply nobody asked the right question... -- Lahwaacz (talk) 12:30, 16 October 2015 (UTC)
Oops, it does not work without -d /. Then the problem must be on aria's side, which expects a file name for the -o option, which is then catenated with -d into the full path. Assuming that -d defaults to the cwd, /var/cache/ would appear twice in the result. -- Lahwaacz (talk) 12:43, 16 October 2015 (UTC)

pacman cache

I still think we should warn people not to symlink /var or anything under it. It leaves the whole system unusable because if the cache disappears during a pacman transaction, you're left with missing /usr/lib libraries, and nothing works, including pacman itself. This is a serious enough problem that it can take hours to figure out how to recover. If the wiki had mentioned this problem it would have saved me a lot of time and effort, and I'm not the only one who has run in to this. It is not, however, considered a bug. See JimRees (talk) 23:15, 29 April 2017 (UTC)

This revisions says that: [5]. But to make it more clear: [6] -- Rdeckard (talk) 00:13, 30 April 2017 (UTC)
Actually, I undid my change since I think that first change is more accurate (mentioning /var/cache/pacman/pkg and ancestors), so I went back to that but explicitly mentioned /var as an example. -- Rdeckard (talk) 01:11, 30 April 2017 (UTC)
Thanks for the background information. I was not aware of the bug report and now clearly understand why you altered the section the way you did. I hope the recent change is sufficient for you. Since every misbehaving program might leave a system unbootable if it plays a role in the boot process, it should be unnecessary to add this redundant information. However the problem you described is still severe and I hope you agree that the recent edits made to the article do the topic justice. Thanks for clarifying the topic and adding this to the article and sorry for reverting your edits at first. -- Edh (talk) 21:07, 30 April 2017 (UTC)

local repository database extension/compression recomendation

If you opt to not compress a pacman database, the files database can become very large, 10x larger than a gzipped one in my case, which cause issues when trying to update the local pacman files db (pacman -Fy) since apparently there is a max (expected) size. Should we include a warning about uncompressed databases?

—This unsigned comment is by JoshH100 (talk) 00:35, 29 January 2019‎. Please sign your posts with ~~~~!

Use a new nginx.conf for Dynamic reverse proxy cache using nginx

I propose to replace the current nginx.conf with an improved nginx.conf and update the section. The new config doesn't make the upstream servers directly available on the network and it allows having mirrors with different relative paths to package files. It also removes directives that are not needed and has some other minor cleanups. I've been using a similar config for a few months now without any problems, so I believe it should be fine. Noctavian (talk) 16:05, 28 February 2019 (UTC)

What do you mean by "The new config doesn't make the upstream servers directly available on the network"? -- Lahwaacz (talk) 20:54, 28 February 2019 (UTC)
In the new config the server blocks for the upstream mirrors are set to listen to Only the computer that is running the nginx cache can send requests to Other computers on the network can't. The current config exposes the upstream mirrors to the network, a nmap scan will show the 8080 port of the cache as open and the ports 8001, 8002, 8003 of the upstream mirrors as open. One can browse to cache.domain.example:8002 and have direct access to whatever package mirror website is used by the cache bypassing the cache config order and locations. The upstream mirrors don't need to be available to the entire network for the cache to work; they only need to be available to the computer that is hosting the nginx cache. I believe ports should not be left open on the network if they don't have to be open. Noctavian (talk) 08:37, 1 March 2019 (UTC)
I have written a draft for the section update on my user page. I made some small changes to the config file since last week, added comments and mirror examples and turned off IPv6 address resolution to prevent some errors that can happen sometimes. Suggestions.are welcome. I haven't seen objections to my proposal, so I'm going to wait a few more days for feedback and then update the section on the main page with my draft and the new nginx.conf file if that's ok. Noctavian (talk) 11:43, 8 March 2019 (UTC)
Feel free to go ahead. -- Lahwaacz (talk) 17:11, 16 March 2019 (UTC)

Do what to "Removing everything but base group"

Section #Removing everything but base group is out-of-date as it talks about "base group", which is a meta package base since [7]. To remove everything but the base package also means to not have a kernel package installed, which does not sound good to me. Should we remove this section? Is there any pratical reason for adapting it for the meta package base? -- Josephgbr (talk) 03:23, 21 October 2019 (UTC)

It could be updated by changing all packages to be installed as dependencies (this is easy with the -D flag, which I think appeared after this section was written), then manually changing the base package and other essential packages like linux or linux-firmware to be installed as explicit, and finally removing all orphans (there is already a section for this). The section could be renamed to "Removing everything but essential packages". -- Lahwaacz (talk) 07:13, 21 October 2019 (UTC)
Following the above idea: How about having the instructions changed to (in separate lines) run # pacman -D --asdeps $(pacman -Qqe) (all currently explicitly to as dependencies) and # pacman -D --asexplicit base linux linux-firmware (essential packages as explicitly), in this last case mentioning to add any other package the user considers essential and wants to keep installed; then tell to follow removal instructions from #Removing unused packages (orphans) ? -- Josephgbr (talk) 12:44, 23 October 2019 (UTC)
Changes applied in Special:Diff/587910. Let me know if any improvement is required. -- Josephgbr (talk) 05:49, 6 November 2019 (UTC)
I made some changes, but overall it looks good. Thanks! -- Lahwaacz (talk) 08:53, 6 November 2019 (UTC)

base meta package and the "Packages and dependencies" section

#Packages and dependencies section lists "explicitly installed packages not in base nor base-devel with size and description", considering both base and base-devel as package groups. Since base is now a meta package, this should be changed.

Currently the command is:

$ expac -H M "%011m\t%-20n\t%10d" $(comm -23 <(pacman -Qqen | sort) <(pacman -Qqg base base-devel | sort)) | sort -n

Here is a command to list packages that base depends on, along with base-devel:

$ expac -H M "%011m\t%-20n\t%10d" $(comm -23 <(pacman -Qqen | sort) <(echo "$(pacman -Qqg base-devel) $(pactree -u base)" | sort | uniq)) | sort -n

May I change? Any other consideration?
-- Josephgbr (talk) 13:22, 6 November 2019 (UTC)

Hmm, it seems this discussion also applies to #Not in a specified group or repository, which has almost the same command based on pacman -Qqg base base-devel -- Josephgbr (talk) 13:27, 6 November 2019 (UTC)
I think this is a good idea. I've just been trying this out and I think echo "$(pacman -Qqg base-devel) $(pactree -u base)" is incorrect as the second command output starts on the last line of the first command, this causes the last package in the base-devel group to be missed as in my case its seen as which base rather than them being seperate packages. I think the snippet should be echo echo "$(pacman -Qqg base-devel & pactree -u base)" instead. However I don't think this completely applies to the #Not in a specified group or repository, as base is still a group so the examples for that section still apply. Maybe the section should be renamed Not in a specified group, repository or metapackage? - 8633brown (talk) 22:14, 8 February 2020 (UTC)
Thanks for the feedback, 8633brown. Fixed the command line and applied in the following Edit IDs 598660 and 598662 for section #Packages and dependencies, and 598668 and 598674 for section #Not in a specified group, repository and meta package.
Please notice that "base" is not a group anymore. Some packages still had to be updated to remove such group name, but now it seems to be done, as can be confirmed by running $ pacman -Sgg base and looking at the list of the (zero) packages of base group.
-- Josephgbr (talk) 20:37, 23 February 2020 (UTC)