Pamac / libalpm incompatible with 'Include = /etc/pacman.d/*.conf'?

Support Virtualization
,
1

I’m running QubesOS, a Xen-based distro streamlining service/domain separation into individual VMs.

I’m striving to, in an Arch-based template, make AUR-access easy via pamac, which AUR has supplied along with its support library without a hitch.

Turns out, that the QubesOS-supplied Arch template out of the box comprises, in its /etc/pacman.conf file the following line:

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

which enables them to provide various 90-custom_repo.conf_inactive files in that directory, which are activatable by simply soft-linking them to equivalent paths devoid of the _inactive bit.

pacman (e.g. -Syu) deals just fine with this, but pamac update chokes with the error

... alpm_config.vala:367: File '/etc/pacman.d/*.conf' doesn't exist

Apparently the path is not resolved.

I there any way to make this work for pamac? I would very much like to mock as little as possible with the QubesOS-provided template and stick with their config even while layering pamac on top…

Thanks for any pointers.

2

I think you’d be better off asking in the QubesOS forum:

Right @moderators?

2 Likes
3

This is clearly a pamac-specific question, so I disagree.
Would have preferred to discuss this in the pamac repo, but I do not seem to be able to be granted access to the gitlab instance…

4

OK.

Please provide the output of:

ls -l /etc/pacman.d/
5 
total 84
-rw-r--r-- 1 root root    36 Oct 18 17:47 10-qubes-options.conf
lrwxrwxrwx 1 root root    56 Feb  5 13:40 85-qubes-4.2-current-testing.conf -> /etc/pacman.d/85-qubes-4.2-current-testing.conf.disabled
-rw-r--r-- 1 root root   108 Jan 24 05:30 85-qubes-4.2-current-testing.conf.disabled
lrwxrwxrwx 1 root root    48 Sep 14 14:00 90-qubes-4.2-current.conf -> /etc/pacman.d/90-qubes-4.2-current.conf.disabled
-rw-r--r-- 1 root root    92 Jan 24 05:30 90-qubes-4.2-current.conf.disabled
-rw-r--r-- 1 root root    87 Oct 18 17:47 99-qubes-repository-4.2.conf.disabled
drwxr-xr-x 5 root root  4096 Feb  8 15:39 gnupg
drwxr-xr-x 2 root root  4096 Jan 26 14:07 hooks
drwxr-xr-x 2 root root  4096 Jan 26 14:07 hooks.bin
-rw-r--r-- 1 root root   245 Sep 14 13:58 mirrorlist
-rw-r--r-- 1 root root 51834 Oct  1 15:24 mirrorlist.pacnew
6

Try replacing:

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

…with:

Include = /etc/pacman.d/*

And deal with your .pacnew files, or you WILL get more trouble:

https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave#.pacnew

1 Like
7

Tried, but as expected counterproductive. The entire premise of the controllable soft-linking breaks and pacman then also breaks, while pamac continues to not work and now reports

... alpm_config.vala:367: File '/etc/pacman.d/*' doesn't exist

The plot thickens for libalpm/pamac just not being able to resolve the path and understand the glob (*).

8

Hmmmmm…OK, nope. I have no idea, so I’m out!

9

You should probably open an issue at Applications / libpamac · GitLab.

10

QubesOS is indeed a very good implementation of the concept separating different tasks.

For one thing pamac is not build with Arch Linux in mind but Manjaro.

I cannot really imagine why you want to use Pamac inside the Arch template as pacman is the native application.

It also appears quite a strange concept to include everything based on the mere appearance.

The files in question will have a content which - depending on the location of the include line - will inject third party repository and possibly replace system files.

When included like you describe you are per definition including 3rd party repos which is not supported - that goes for Arch and Manjaro.

Looking at the code in the configuration parser it expects a named file not a list of files.

11

I would have loved to. But days have gone by and I have not received anything in response to my request to open an account just there.

12

  1. Manjaro itself may be interpreted as just adding additional repos on top of Arch and the QubesOS/Arch team is doing much the same by including a custom repo with the small number of packages required for Arches| seamless integration into the QubesOS ecosystem. They do it in a way that is quite elegant (especially from the perspective of configuration management engines such as salt etc.), as activating/inactivating just requires softlinking and NOT config file editing. Sadly libpamac appears less flexible in this respect than pacman.

  2. The motivation of using pacman within the QubesOS-community provided Arch template is to have a convenient client to deal with AUR packages.
    While I maintain a pure Arch template as provided (and obviously using pacman only), another part of Arch’s appeal is the availability of AUR and a AUR-using template (cloned from the pure Arch one) is intended to provide seamless install of packages from their using AUR.

13

I’m guessing you mean pamac. Anyway, you’re better off using any other aur helper IMHO.

1 Like
14

The QubesOS is quite elegant - I have been using it myself - for educational purpose. I believe I have been around version 2 and 3 - perhaps version 4 as RC.

Then there is something you don’t know. Manjaro is not an additional repo on top of Arch Linux.

While the package majority is indeed build by Arch Linux not every package provided within Arch Linux repo is available with Manjaro.

And those which are available is made available within the Manjaro branch structure.

The QubesOS template - is likely to use a customized version of pacman - just as Manjaro uses a customized version.

This will explain why Pamac doesn’t read the pacman.conf correct when presented with a *.conf instruction.

And therefore pamac and libpamac is not compatible with the customised Arch based template available within QubesOS.