Metapac always want to reinstall the same 2 packages

[paolomainardi]

When running metapac s it always tries to reinstall the same two packages:

❯ metapac s
[Arch]
libva-mesa-driver
mesa-vdpau

They, of course are already part of the group file:

❯ cat ~/.config/metapac/groups/base.toml | grep mesa
    "libva-mesa-driver",
    "mesa-utils",
    "mesa-vdpau",
    "mesa",

Is this is an issue from my side or it's a bug?

Running the latest version:

❯ metapac --version
metapac 0.2.3

[ripytide]

What does pacman -Qi mesa-vdpau show? Perhaps they are installed as dependencies and not explicitly and so metapac wants to install them explicitly?

[paolomainardi]

Thanks for your quick reply @ripytide!

They are explicitly installed:

❯ sudo pacman -Qi mesa-vdpau libva-mesa-driver | grep "Install Reason"
Install Reason  : Explicitly installed
Install Reason  : Explicitly installed

But from what I understood, they are now just aliases of the mesa package: https://archlinux.org/packages/extra/x86_64/mesa/

I am unsure how I've compiled the list for Metapac; maybe they were standalone packages in the past. Anyway, I guess this is a case to handle.

[ripytide]

Ah ok, so mesa-vdpau and libva-mesa-driver are both Virtual Packages so are ambiguous to metapac since there may be multiple real packages which provide them. So perhaps we should throw a warning stating as much when we encounter such virtual packages?

[paolomainardi]

@ripytide Yes, it would be handy; I would also add to the message the "real" package that should be used instead.

[ripytide]

Unfortunately, it seems there is no proper way to list packages providing a virtual package as far as I can tell: https://www.reddit.com/r/archlinux/comments/uxgwk5/how_to_list_every_package_that_provides_virtual/ so we may just have to result to a warning plus a suggestion to run pacman -Si <package> or even pacman -S <package> which seems to resolve virtual packages into real packages somehow.

[paolomainardi]

I am going to test it again, but doing **pacman -Su ** does not solve the issue, metacap will try to install it again, I guess because it doesn't understand virtual packages.

[paolomainardi]

The current situation is:

1. User adds a virtual package to metapac
2. metapac s will try to install virtual package, which ends up installing the actual package (in my case mesa)
3. metapac u detects a missing package installed in point 2.
4. metapac s still tries to install virtual packages.

I don't know if those packages are virtual packages as the documentation states that they are installable; that's not this case, in this scenario the old package is just redirected to the new one, the specific case where packages were merged together: https://gitlab.archlinux.org/archlinux/packaging/packages/mesa/-/commit/825be1410117ed165a6eee7a11e3a3e3cce2ae4b

I guess it is managed by replaces block: https://gitlab.archlinux.org/archlinux/packaging/packages/mesa/-/blob/main/PKGBUILD?ref_type=heads#L260

Maybe there is a way to query the pacman database to ask what replaces a package?

[ripytide]

I can't find them as packages on https://archlinux.org/packages and pacman -Si mesa-vdpau returns error: package 'mesa-vdpau' was not found which leads me to believe that they are not actual packages and so instead there is some special logic in pacman -S <package> that goes something like "if a the requested package cannot be found but is provided by exactly one package then just install the providing package".

I don't think there is a built-in way to query the database for replacing packages, other than iterating through every package in the database and doing pacman -S --print-format %R but that doesn't seem very efficient.

Regardless, I think a user having virtual packages in their group files is a fundamental ambiguity and so metapac shouldn't accept them and should tell the user as such with a warning so they can manually replace those virtual or outdated packages with their up-to-date counterparts.

[ripytide]

I've opened a PR (#52) to check that packages are in fact real packages and provide a hefty warning if they aren't. Here is the warning I've put together:

 WARN  metapac::backends::arch > arch package "mesa-vdpau" was not found as an available package and so was ignored (you can test
if the package exists via `pacman -Si "mesa-vdpau"` or similar command using your chosen AUR helper)

it may be due to one of the following issues:
    - the package name has a typo as written in your group files
    - the package is a virtual package (https://wiki.archlinux.org/title/Pacman#Virtual_packages)
      and so is ambiguous. You can run `pacman -S "mesa-vdpau"` to list non-virtual packages which
      which provide the virtual package
    - the package was removed from the repositories
    - the package was renamed to a different name
    - the local package database is out of date and so doesn't yet contain the package:
      update it with `sudo pacman -Sy` or similar command using your chosen AUR helper

What do you think?

[paolomainardi]

We can also add this command to the warning:

❯ sudo pacman -Ss libva-mesa-driver
extra/mesa 1:24.2.7-1 [installed]
    Open-source OpenGL drivers

Which can help to know which packages now provide the package.

I don't know the internal of metapac, nor if it's implemented on the libalpm library. This function can be helpful, I think that it's the very same used by pacman to do the trick: https://github.com/archlinux/alpm.rs/blob/master/alpm/src/package.rs#L237

[InnocentZero]

@paolomainardi I'm also on arch. Afaik recently the packages were merged.

[paolomainardi]

Thanks @ripytide