Talk:Pacman/Tips and tricks

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: [1], [2]. 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 https://bugs.archlinux.org/task/50298. JimRees (talk) 23:15, 29 April 2017 (UTC)

This revisions says that: [3]. But to make it more clear: [4] -- 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 127.0.0.1:800X. Only the computer that is running the nginx cache can send requests to 127.0.0.1. 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)

Remove uninstalled packages from the cache with paccache

Just figured the following out, noting here since I'm not sure it's worth noting in the page itself: paccache won't remove uninstalled packages, even with -u, unless -k is given a value lower than the number of instances in cache. In particular, oneshot AUR experiments won't be removed without -k0. Gesh (talk) 01:23, 1 November 2021 (UTC)

The -u flag just adds all installed packages to the blacklist. So to remove uninstalled packages from the cache and nothing else, use -uk0. — Lahwaacz (talk) 06:28, 1 November 2021 (UTC)

Additional options needed for mounting overlay of remote pacman pkg cache

"The factual accuracy of this article or section is disputed. Reason: Why is -o index=off -o metacopy=off needed? Is -o redirect_dir=off needed only for this use-case? If not, it should be explained on the overlay filesystem page too."

My reply: I'm not an expert on use of sshfs for mounting remote filesystems. To me, using sshfs is much simpler than going to all the trouble of setting up the chosen box to serve up /var/cache/pacman/pkg over, e.g., NFS. I wonder if using fuse.sshfs leads to this problem? That being said, my setup is bog standard, all boxes using linux kernel from Arch, connected to the same LAN switch with normal IPv4 addressing, e.g., 192.168.1.100, and so on.

Without using any additional options the problem I encounter is an unusual but familiar one, namely:

$ ls /tmp/pacman_pkg/ > /dev/null
ls: reading directory '/tmp/pacman_pkg/': Stale file handle

This is obviously unworkable. The minimal options I am able to succeed with are: -o redirect_dir=off -o index=off. Prior to the 5.17 kernel series, I needed -o index=off -o metacopy=off but in my use something then changed which requires -o redirect_dir=off (and -o metacopy=off now comes along for free). Without these options... "Stale file handle".

I am eliminating additional options from the generic commands even though I expect that anyone who tries to run them as listed will fail due to the file handle reporting as stale. I will add a tip note suggesting these options if problems are encountered. HTH :) Cmsigler (talk) 16:21, 27 April 2022 (UTC)

I'm not super familiar with sshfs, but this looks good to me! Thanks for addressing the accuracy template ^^ CodingKoopa (talk) 06:48, 2 May 2022 (UTC)

Is PackageKit still not recommended to use in 2022?

In Pacman/Tips_and_tricks#Graphical, a warning says that PackageKit opens up system permissions by default and thus is not recommended to use. However, that warning was added back in 2018 and it links bug reports from 2016. I'm wondering if it's still valid in 2022? Also, as far as I know, PackageKit only allowed users from the wheel group to perform updates (kind of similar to what sudo does).

Is this still the case nowadays? If so, are there any other warnings one should know of before using PackageKit? I'm thinking partial upgrades, but I'm not sure. Cont999 (talk) 03:54, 3 September 2022 (UTC)

sudo pacman requires a password, whereas PackageKit doesn't, so they are really not equivalent. I believe PackageKit can also update the system even if the user is not in the wheel group. I haven't looked upstream, but this is how the software is designed to work because it fits the way other distributions configure things. In Fedora, for example, you do not need to authenticate to install updates to the system. Updates can also run without user intervention. These practices are dangerous on Arch. Unattended updates aren't supported and attended ones require you to read the output and the News. So the problems using PackageKit on Arch are not going to be resolved unless changes are made locally, but there's not much motivation to do that as Arch users are expected to be able to use pacman. That is, the bugs on Arch aren't bugs elsewhere, so upstream is unlikely to fix them (and break how stuff works elsewhere); the bugs are more easily avoided on Arch by not using PackageKit. At least, that would be my understanding. --cfr (talk) 01:11, 13 December 2022 (UTC)

Why do I have this package?

I occasionally wonder why a certain PACKAGE is installed. I used to browse pactree -r PACKAGE to answer this question, but I recently figured that you can just do pacman -Qe `pactree -ruo PACKAGE` to list all explicitly installed packages that directly or indirectly depend on PACKAGE.

I would've added a section to the article but I'm not sure if this is useful for anyone but me. Rumsbums (talk) 07:58, 21 January 2024 (UTC)

to list all explicitly installed packages that directly or indirectly depend on PACKAGE.

The question is, why do you want to know that in the first place? What purpose such information can serve?

If you have some explicit package you don't need, just uninstall it. If it is required by something else, pacman won't let you uninstall it anyway. In which case you can simply mark it as non-explicit (pacman -D --asdeps PACKAGE).

Also this maybe a bit obvious, but you should not uninstall base metapackage of course. It is a special case and core of the proper Arch installation.

Hanabishi (talk) 08:17, 21 January 2024 (UTC)

To add to this, you can run pacman -Rsc --print package to see what would have been removed. — Lahwaacz (talk) 14:07, 21 January 2024 (UTC)

A CacheServer which is using the database files

In the past, there was a tip about a CacheServer that does use the database files. I find it useful, for example when the admin would like to have all his machines refers to exactly the same database files. My edit to get it back was rejected. A solution might be to divide Pacman/Tips and tricks#Network shared pacman cache into two sections. One section will discuss a CacheServer which is using the database files. The other section will discuss a CacheServer which does not use database files. Any opinions? Regid (talk) 07:59, 10 October 2024 (UTC)

A CacheServer in pacman does not use database files, please don't call your solution like that. — Lahwaacz (talk) 06:54, 12 October 2024 (UTC)

In the context of the suggestion for the clients to have a CacheServer statement in their /etc/pacman.conf, is the following acceptable?

Note: if you want to force the clients to use only packages from the cache server, you can

# ln -s /var/lib/pacman/sync/*.db /var/cache/pacman/pkg/

in the server, and use the common

/etc/pacman.conf

Server = http://server-ip:port

statement for each client.

Regid (talk) 12:25, 12 October 2024 (UTC)

No, if you use Server, it is not a cache server. In your use case, the clients will not be able to download packages missing on the cache server and if you add another Server directive for that purpose, you won't get exactly the same packages served by both servers (if your "cache" server becomes outdated, the other mirror will purge its old packages in the mean time).

I really doubt that this tip is worth mentioning on the page.

— Lahwaacz (talk) 12:50, 12 October 2024 (UTC)

It would be a cache for the packages the cache server has. The intention is the client will not be able to download packages that the cache server admin has not approved. He will not add another Server directive to the clients. Quoting Package Proxy Cache:

If you want to install the same Arch packages over and over - e.g. for testing purposes - it could help if you would not have to get the packages every time from the internet.

Or someone might want to have a group of machines with exactly the same set of packages. And the original tip was here for a long time. I find that tip useful.

—This unsigned comment is by Regid (talk) 17:27, 12 October 2024. Please sign your posts with ~~~~!

The original intention was not to forbid downloading packages that are not already in the cache. It said to add Server at the top of the mirrorlist, not to use it as the only entry. This solution had the exact issue that I described, which is solved by using CacheServer since pacman 6.1.0. Your quote from Package Proxy Cache is just a definition of a cache server and the CacheServer also does exactly that. — Lahwaacz (talk) 17:35, 12 October 2024 (UTC)