Separate pacman and AUR packages in package count for Arch-based distros

[ObjectsCountries]

Hello everyone,

I'm thinking of making a pull request that adds an option to separate pacman packages from AUR packages when listing the number of packages on Arch Linux-based distributions (i.e. Packages: 600 (pacman), 400 (AUR), 30 (flatpak) and so on). Additionally, I'd like to include an option to separate repositories as well (i.e. Packages: 100 (core), 200 (extra), 300 (multilib), 400 (AUR), 30 (flatpak) and so on). Is this something that anyone might be interested in?

From what I can tell, I would need to include the ALPM C library, is that okay? Also, should this use the combined option of the Packages module? This option is a boolean, but maybe it could be changed to be either a boolean or a string: false to separate all pacman repositories, true to combine pacman's package count with the AUR's, and maybe something like "pacman" to combine all of pacman's repos and display them separately from the AUR. If I need to create a separate option, I can do that as well.

I'm on Artix Linux, so I will be able to test this myself, as well as account for repositories other than core, extra and multilib. One last thing: I promise not to vibe-code this at all.

[CarterLi]

Packages: 600 (pacman), 400 (AUR), 30 (flatpak)

Considerable

Packages: 100 (core), 200 (extra), 300 (multilib), 400 (AUR), 30 (flatpak)

What about custom repos? And if we do this for pacman, should we do the same for apt, rpm, apk, etc? No for me.

include the ALPM C library

Only dlopen is allowed, since we have not only Arch users. I worry about the performance penalty. Currently we count directories in /var/lib/pacman/local directly which is very fast. If we use ALPM can we still get the same performance?

[ObjectsCountries]

In that case, maybe we can make use of the combined option in the Packages module as it is to combine pacman with the AUR when true, and list them separately when false. As for detecting whether a package is from pacman or the AUR, I'll admit that I'm not too sure. I know that pacman -Qm lists packages not on the official repos, which will be from the AUR 99% of the time. But I'm not sure how to implement it without trying to decompress and read the files in /var/lib/pacman/sync/ (which are just *.tar.gz files without the extension, from what I can tell). Additionally, should we use "foreign" or "AUR" for this separate category?

From a quick glance at pacman's source code, it looks like pacman -Qm uses ALPM under the hood. As you said, we can only use dlopen, so how would that work? I see a /usr/lib/libalpm.so in my Artix system, would we need to use dlopen to mess around with that?

[CarterLi]

Yes, you have to dlopen /usr/lib/libalpm.so. There is some helper macros in common/library.h. Please see other files for reference.

[ObjectsCountries]

I added some code to my fastfetch fork to add a placeholder function for foreign pacman packages.

ObjectsCountries@a7663e8

Here's what it looks like so far (I actually have 15 foreign packages on my system according to pacman -Qm | wc -l, the 67 is just a temporary return):

And with combined set to true:

I think everything's good, but I'm a bit unsure about if I modified src/modules/packages/packages.c properly. Please let me know if any changes are needed before I implement the foreign package detection.

[CarterLi]

LGTM