Ovelayng repositories break information

[oech3]

trafficstars

Some Arch based distribution overlays repositories for same package (see https://wiki.cachyos.org/features/optimized_repos/). In the setting, same package with different repository appears 2~3 times. Moreover, I can't determine by pacfinder where chromium comes from while pacman -Qi chromium shows Installed From : cachyos-extra-v3.

related? : https://github.com/stevenbenner/pacfinder/issues/10

[stevenbenner]

Thanks for the bug report. I did a little initial research on CachyOS, as I wasn't aware of the project. This distro (specifically their libalpm) seems to diverge from Arch in a couple ways. Which might complicate matters.

Potential for incompatibility with a pacman fork

What the CachyOS distro is doing seems like more than an "overlay". The CachyOS developers have forked pacman then added new features and some different behavior to it. The wiki page you linked warns about this:

Installing the CachyOS Pacman will install a forked pacman with features added from CachyOS, like “INSTALLED_FROM” and an automatic architecture check. [...]

The "Installed From" data that you're referencing does not exist in the original version of pacman. For example, if I run pacman -Qi chromium on Arch then I receive the following output:

> pacman -Qi chromium | grep 'Install'
Installed Size  : 333.78 MiB
Install Date    : Sun 06 Apr 2025 05:55:41 PM PDT
Install Reason  : Installed as a dependency for another package
Install Script  : No

It looks like that origin DB feature was added to the CachyOS fork of libalpm in CachyOS/pacman@a8a7114a6ec9f9a1cab2e4b91c649142f084a74f.

So CachyOS is not running the same pacman/libalpm that PacFinder was designed for. Depending on the differences that may or may not be a problem. From what I can tell, their approach seems to maintain compatibility with Arch packages and repos, but not necessarily with the pacman/libalpm CLI/API/ABI. There are too many commits for me to have developed an understanding of the fork - so I don't know if any incompatibilities have been introduced which could effect PacFinder.

I'm not keen on the idea of adding code to handle a specific fork of libalpm. For true support I would also need to set up a CachyOS playground to properly test and debug it. Then maintain support for their fork and any future changes indefinitely. So if this is an incompatibility with vanilla pacman then a fix likely will not be forthcoming - unless I randomly decide to distro hop to CachyOS.

Next steps

However I would be happy to look into the issue with you. I don't yet know if PacFinder isn't working properly with the more complicated collection of sync databases or if there is an incompatibility issue. The CachyOS scenario might be triggering a PacFinder problem that I haven't encountered. Or there might be a way to improve the behavior, if I better understand it. So I would be grateful if you would help me with a bit of diagnostic work.

I need to better understand what is happening. So a few follow-up questions:

1. Can you provide screenshot(s) of what PacFinder is showing? I need to know exactly what you're seeing to understand the problem. Or tell if it even is a problem.

2. Could you provide the contents of your /etc/pacman.conf file? It would help me to know your configuration.

3. Can you provide the output of pacman -Qs chromium? See what pacman knows of the package in the local database.

4. Can you provide the output of pacman -Ss chromium? See what packages and sync databases pacman knows about, and their installation status.

5. Is the package shown multiple times in any view other than the "All Packages" list? This might not even be a bug. If there are multiple databases with the same package then it is expected to see them in the all packages list. The common use for this are the testing repositories. Though it should show the appropriate name in the repository column.

6. Do you have multiple CachyOS versioned repositories enabled in pacman? Do you perhaps have both "cachyos-extra-v3" and "cachyos-extra-v4" enabled - or something to that effect? If I'm understanding the documentation correctly, then I think it is expected that only the repos for your specific architecture are enabled. But I might be wrong about that.

[oech3]

Thankyou for replying.

1. screenshots: Sorry about setting dark mode. I remark that binutils of [core] is checked by green icon. It is wrong(see also answer for 4.). Listing binutils 3 times itself is useful for some people. Check mark should be enabled only for installed one. (Feature Request: check mark should be left of package name).

2. pacman.conf:

   [options]
   #Some opts are omitted
   Architecture=auto
   SigLevel=Required DatabaseOptional
   LocalFileSigLevel=Optional
   
   [cachyos-v3]
   Include=/etc/pacman.d/cachyos-v3-mirrorlist
   [cachyos-core-v3]
   Include=/etc/pacman.d/cachyos-v3-mirrorlist
   [cachyos-extra-v3]
   Include=/etc/pacman.d/cachyos-v3-mirrorlist
   [cachyos]
   Include=/etc/pacman.d/cachyos-mirrorlist
   #v4 is excluded
   
   [core]
   Include=/etc/pacman.d/mirrorlist
   [extra]
   Include=/etc/pacman.d/mirrorlist
   

3. pacman -Qs binutils (may better than chromium):

   local/binutils 2.44-3
       A set of programs to assemble and manipulate binary and object files
   

4. pacman -Ss binutils:

   cachyos-v3/binutils 2.44-3 [installed]
       A set of programs to assemble and manipulate binary and object files
   cachyos-core-v3/binutils 2.44-1.1 [installed: 2.44-3]
       A set of programs to assemble and manipulate binary and object files
   core/binutils 2.44-1 [installed: 2.44-3]
       A set of programs to assemble and manipulate binary and object files
   

5. Yes except for repository section (see also screenshot)

6. v4 is excluded. I have [cachyos-v3],[cachyos-core-v3],[cachyos-extra-v3],[cachyos], [core] (of Arch) and [extra] (of Arch).

Additional info: pacman 7.0.0.r6.gc685ae6-3 Oh no. pkgver is same with Arch's one.

(Comment edited by stevenbenner: Fixed formatting for GitHub)

[stevenbenner]

That information is indeed helpful. Thanks for providing the screenshot and additional details. I think that I have an idea of what is going on.

The problem (probably)

A package is identified by its name. So if any binutils package is "installed" then all of them are considered "installed". PacFinder isn't currently considering version information -let alone the fork extended "installed from" data- when determining a package's installation state.

First thoughts on a fix

What usually differentiates packages with identical names in different repos is their version number. My initial thought for a fix would be to filter the installed status with a version comparison - and only consider a syncdb package installed if the version number matches the localdb version. That seems to be what vanilla pacman does. However that would only work so long as the version numbers are never the same across different repos. I'm not sure if I can count on that being true for all packages in the CachyOS ecosystem. A version number collision would be a problem. For example, if the [core] and [cachyos-core-v3] binutils packages had identical version numbers then a version check would show both as "installed". So a version comparison would not fix the problem in such a case.

The big gotcha of using version number to determine installation status is when the syncdbs move ahead of the localdb. If mypkg v1 was installed, then mypkg v2 is published and the user does a pacman -Sy (update syncs, but don't upgrade software) then a dumb version check would say that mypkg is either not installed or installed as a foreign because v1 wasn't found in the syncdbs.

I see why the CachyOS devs added the "installed from" installed_db data to their fork. It would be very helpful data for scenarios like this. An installed_db property might just be the only way to handle such a case.

Relevant scenarios

This bug likely applies to packages installed from the testing repositories as well. I almost never use them, so that scenario is poorly tested. In the testing repositories it is always guaranteed that the version number will be different than the packages in the main repositories. It would also less confusing for users of the testing repos because there would only ever be at most two of a package and the repo column makes it clear what is happening.

A fix also has to potential to interact with the unresolved issue described in #10.

Next steps

I'll think about this problem a bit and and do some code research on pacman/libalpm to see if I can find a vanilla solution. After my next system update I'll also turn on the testing repos to see how PacFinder behaves. No promises on a fix yet though. A truly robust solution might be a non-trivial problem - especially as I am limited to vanilla libalpm features and cannot use the CachyOS libalpm features.

A version number comparison fix might be an improvement over the current behavior - even if it doesn't resolve every scenario and has the potential to cause new problems. It would have prevented the binutils issue you described. It should also be a simple and low-risk patch.

Would you happen to know the answers to any of these questions:

1. Does CachyOS have any rules about the version numbers that they give their packages?
2. Are version numbers always guaranteed to be different in different CachyOS repos?
3. Why is there a binutils package in both [cachyos-v3] and [cachyos-core-v3]?

[oech3]

It seems Cachy use Arch's ${pkgver}+.1 to override Arch's one by updating. (So I assume binutils 2.44-3 in [cachyos-v3] is mistake. ) However, pacman(https://github.com/CachyOS/CachyOS-PKGBUILDS/issues/569) mesa dkms etc... are exception. Cachy's dkms use clang instead of gcc. So pkgs with Cachy specific change may also exception.

@ptr1337 Right?