why pacman uses .d so weirdly?

gcb · 2025-06-08 13:33:16

trying to get rid of pacman.d/mirrorlist.pacnew on every update, i did the obvious thing and left the mirrorlist file untouched and created a mirrors-local file. But pacman seesm to use pacman.d as just a random dir, filenames are still 'hardcoded'

why on would one use /etc/pacman.d/[mirrorlist,gnupg,hooks] instead of /etc/pacman/[mirrorlist,gnupg,hooks]?

I would expect .d directories to glob all configs files alphabetically, like all other applications do. It is so misleading with pacman.d.

Even more infuriating is that i can probably fix it on pacman.conf, but then i will get pacman.conf.pacnew

/rant

Last edited by gcb (2025-06-08 13:34:42)

cryptearth · 2025-06-08 13:40:18

well - first of all: no matter what application you want to use - it has to support it!
example: lets say I developed a new tool useful to many because it does a good job
but I as the dev have decided that its config will be a single flat file in /etc without any directory or option for additional drop-in configs

commibg back full circle: to answer your WHY? because some pacman dev has decided so many years ago

if you feel that's wrong feel free to modify pacman and open a PR in its repo - its up to the maintainers to decide

seth · 2025-06-08 14:52:09

Check your pacman.conf, how does the mirrorlist get … errr… "added"?
Then see https://man.archlinux.org/man/pacman.conf.5#OPTIONS
Then see the same manpage for NoExtract

But pacman seesm to use pacman.d as just a random dir, filenames are still 'hardcoded'

It's more that the mirrors are repo-specific, just including random config files into every! single! repo! would spell disaster and wreak havoc. We're talking cats and dogs 69ing in the streets.

Even more infuriating is that i can probably fix it on pacman.conf, but then i will get pacman.conf.pacnew

Are you suggesting you're currently using the default pacman.conf? No colors? No candy? No multilb? No NoExtract??

snakeroot · 2025-06-09 18:33:26

Here's how I dealt with it, based on this helpful suggestion from the wiki.

Added the following to the top of my pacman.conf file:

Include = /etc/pacman.conf.d/*.conf

Created the directory /etc/pacman.conf.d

Created the file /etc/pacman.conf.d/10_NoExtract.conf containing the following text:

[options]
NoExtract = etc/pacman.d/mirrorlist

When I first made this change earlier this year, as you posited it did create the (annoying) /etc/pacman.conf.pacnew file on pacman upgrade. However, a grep of my pacman.log indicate that for the upgrades earlier this month it did not do so.

gcb · 2025-06-10 00:24:44

seth wrote:

Are you suggesting you're currently using the default pacman.conf? No colors? No candy? No multilb? No NoExtract??

? ...y.. yes? Aren't we all?

I do think colors, parallel download etc to be usefull. but noextract i avoid. I do want to see pacdiffs and check what was changed. I fully trust the maintainers to know better than i do and i do not want to miss 'new default' changes. Another reason why i love conf.d pattern when used in full. ...after reading all the comments here i might open the first exception for the mirrorlist file tho.

snakeroot wrote:

Here's how I dealt with it, based on this helpful suggestion from the wiki.

Agree, i might need noExtract that file... for the new include, since the default is to not load everything from that dir, I only replaced:

-- Include = /etc/pacman.conf.d/mirrorlist
++ Include = /etc/pacman.conf.d/99_gcb_custom

Not sure if something will ever place a file i don't expect there or i'm just being weirdly paranoid by not using *.conf there.

... i will probably mislead myself when i add some /10_local_changes or something, but that's something for tomorrow-me. Not me!

cryptearth · 2025-06-10 04:59:33

@snakeroot
I see several issues with your "solution" and hence it can't be called such

- (multiple) redefinition of the same section: although I wasn't able to confirm this and I'm not familiar with how pacman does its parsing but the general consent about ini-style configs seems to be that every section should be definied exactly once only
your "solution" violates this and hence the behaviour is undefined at best

- order of inclusion: although it seems pacman can handle multiple includes just fine I would put a general "include all" at the bottom instead of the top to guarantee that at least the main master config loads correctly
putting this include all at the top comes with the risk of breaking the entire config as in "what happens if the first option is outside the [options] section?"
having this line at the bottom would result in the parameter given be seen as part of the last parsed section in case a section is missing in the included file

- recursive include: have you tested recursive or, even worse, circular includes?
what happens when A includes B which includes A or one of the included configs includes the master config again? I see a stackoverflow incoming - if someone somehow gains access to such a chain it's a perfect vector for denial-of-service or worse - depending on what one can pacman abuse to with such a config

overall my initial reply holds true: if pacman doesn't offer such kind of drop-in conf dir don't try to recreate such on your own without having in-depth knowledge of all source involved and also have an idea about such edge cases
I won't be surprised if in two years someone comes up with some weird issue which is based on your "suggestion"

Allan · 2025-06-10 05:21:12

FYI, pacman can read configs that go in and out of sections fine. And prevents recursive inclusions due to having a limit on inclusion depth.

And the reason the directory is named pacman.d without reading it for inclusions is that it was added right as adding a ".d" was becoming a thing, but it had not become a standard for automatically reading inclusions at that time. No-one has touched it since then. We probably want /etc/pacman/... for files to be included via the Include directive (such as mirror list config) and the gnupg config and /etc/pacman.conf.d/ for drop-ins to pacman.conf. I believe there is a feature request around to do this, but it is not considered a high priority.

Arch Linux

#1 2025-06-08 13:33:16

why pacman uses .d so weirdly?

#2 2025-06-08 13:40:18

Re: why pacman uses .d so weirdly?

#3 2025-06-08 14:52:09

Re: why pacman uses .d so weirdly?

#4 2025-06-09 18:33:26

Re: why pacman uses .d so weirdly?

#5 2025-06-10 00:24:44

Re: why pacman uses .d so weirdly?

#6 2025-06-10 04:59:33

Re: why pacman uses .d so weirdly?

#7 2025-06-10 05:21:12

Re: why pacman uses .d so weirdly?

Board footer