pacfinder icon indicating copy to clipboard operation
pacfinder copied to clipboard

Version greater than repo is not displayed

Open oech3 opened this issue 3 years ago • 4 comments

I use some packages in testing repo without including testing repo to pacman.conf. In this case, pacfinder shows versions of packages in non-testing repo.

oech3 avatar May 29 '22 08:05 oech3

I have a couple follow-up questions that may help to narrow down the cause.

  1. Please describe how you installed the packages. This sounds like a special case, so the specific steps for installing them may be important. I need to understand what state the pacman databases are in. I also may need to repeat your install process on my computer to test this.

  2. Can you supply the pacman info about one of the packages? I need to see what pacman thinks is going on. What is the output of the following commands:

    • pacman -Qs [package]
    • pacman -Qi [package]
    • pacman -Ss [package]
  3. What is the version number installed, and what version number is Pacfinder showing you? I'm trying to find out if pacman has different version numbers in the query output.

stevenbenner avatar May 29 '22 09:05 stevenbenner

@stevenbenner

  1. I downloaded package file from web site by clicking 'Download From Mirror' button and pacman -U it.
  2. pacman -Qs booster says local/booster 0.8-1 Fast and secure initramfs generator pacman -Ss booster says extra/booster 0.7-3 [installed: 0.8-1] Fast and secure initramfs generator and about other packages including word booster pacman -Qi booster|grep Version says Version : 0.8-1 Full output are https://pastebin.com/qYYNaxtf
  3. I installed booster 0.8-1.finder says booster 0.7-3 is installed explicitly from extra repo.

oech3 avatar May 29 '22 16:05 oech3

Thank you for the additional information. I think I know what is going on.

PacFinder uses the sync databases (e.g. "extra" in this case) as the metadata source for the non-foreign package list, because the local database does not include dependency relationships for non-installed packages. So it knows that the "booster" package is installed, because it is found in the localdb, but it sources the package metadata (including version number) from the syncdb, because that's where the full dependency list is.

This may not be an easy issue to fix.

I'll take this issue as a bug investigation to-do item. I'm not sure if or when a fix will come for it, because this might take a lot of code to patch.

stevenbenner avatar May 29 '22 18:05 stevenbenner

Notes to self

  • This issue probably applies to rolled-back/held-back (IgnorePkg) packages as well.
  • libalpm doesn't make some of the required structures available for instantiation outside of the library. So a fix may require creating new PacFinder-specific structures for alpm types.
  • This kind of complexity may be a small part of the reason why pacman is so adamant that "Partial upgrades are unsupported".

Option: Custom data getters

Maybe this can be resolved by making getter functions for package metadata that can detect this scenario and dynamically fix it when data is accessed. Perhaps also a smart getter for whole alpm_pkg_t. Though it may require building a custom package list for display.

The tricky part is dependency relationships. Perhaps I should create a getter that will detect a version difference and then build the dependency relationships up manually by merging the syncdb and localdb (syncdb will have known packages that depend on the local package, and localdb will know what the current version of the package depends on).

Option: Full internal package list, with custom getters

The syncdb/localdb differences may affect other scenarios. So it may be more forward compatible to just go ahead and maintain an internal list of packages in PacFinder, instead of simply relying on the lists provided by libalpm.

This could be a bit messy and could bloat the project with alpm->pacfinder translation code.

Option: Patch alpm to include syncdb dependency relationships in localdb entries

If the localdb package data could include dependants from the sync databases then PacFinder could get away with using the localdb as the source of truth for all installed packages.

Though I suspect that the alpm maintainers wouldn't want to adopt the complexity, risk, and future maintenance of a patch like that just to make life a bit easier a small third party utility like PacFinder.

stevenbenner avatar May 29 '22 18:05 stevenbenner