image info --resolve-package-list does not handle DNF variables

[AdamWill]

If you try to use kiwi --resolve-package-list with default Fedora profiles, it fails, because this codepath doesn't seem to resolve dnf repo config variables:

[adamw@toolbx fedora-toolbox-43 fedora-kiwi-descriptions (main)]$ kiwi --profile=KDE-Desktop-Live --kiwi-file Fedora.kiwi image info --description=./ --resolve-package-list > /tmp/kde.txt
[ ERROR   ]: 16:09:30 | KiwiUriOpenError: Failed to resolve metalink URI https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=$basearch: HTTP Error 404: Not Found

that is, it's literally using the repo URI https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=$basearch, when it should resolve $basearch to the host system's arch, or the value of --target-arch if specified (specifying --target-arch doesn't help, I checked).

You can hack around this by doing a string substitution on the config file, of course, but it's a bit of a mess. This works during actual image builds, so it seems like it should be possible for it to work for --resolve-package-list too. Though I think during image builds, it's ultimately passed through to dnf somehow - I can't find any code in kiwi for doing it.

[schaefi]

yes the metalink resolver is not applied for the sat-solver based resolver operation. The code for this lives in kiwi/kiwi/solver. Please note I implemented that solver class to offer a generic method to create a solvable from a repository and solve using the libsolv plugin. When you call --resolve-package-list no package manager will be involved only repository metadata and plain libsolv. This is also the reason why you cannot 100% compare the result with package managers because they can apply further solver mechanics

But I still believe it's helpful which is the reason why the code is still there

I take a look and add the metalink resolver to this code path as well. It should be relatively straight forward. However right now I'm pretty busy with other stuff. As such no promises when I get to it

[github-actions]

This issue is stale because it has been open 60 days with no activity. stale label was set.

[AdamWill]

It's still valid.

[schaefi]

It's still valid.

yes I have added this github action to set the stale label on stuff that isn't touched for longer. The number of stale issues always tells me there are not enough contributors to balance out incoming issues in time. I guess not a new problem :)

[AdamWill]

no problem, I was just touching it in case this was an auto-close workflow, I come across those quite often.

[schaefi]

no worries we never auto close. We take it as subject to the community meeting and decide for the next steps. As such it's handy to see the flags.

[schaefi]

@AdamWill going to fix this today