-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] pkg.installed (aptpkg latest_version) UnboundLocalError on foreign-arch package #66940
Comments
@scy Part of the problem may be that Salt doesn't support 32-bit packages on Linux and hasn't for some time. |
I don't think that should keep it from supporting multi-arch package installation in general though. Even if Salt itself does not support 32-bit anymore, Debian still does, and the issue here basically boils down to simple string matching. Also, multi-arch is not just about x86 vs x64, it also applies to different ARM subarchitectures or even cross-platform emulation with things like QEMU and binfmt. |
@scy FYI dropped support for |
That's alright and understandable, all good. :) I have outlined a simple workaround in the original report above; this is therefore probably a low priority issue. However, I still think we're somehow miscommunicating here. This issue has nothing to do with running Salt on 32-bit machines. Instead, this is about Debian's APT package manager being able to install 32-bit packages on 64-bit machines, which are completely unrelated to Salt's supported architectures. In fact, I could even install ARM packages on my AMD64 machine and run them transparently with QEMU, Linux supports these kinds of shenanigans. This issue is just about Salt not stumbling over cross-architecture packages that I wish to install. |
@scy Understand, have done all manner of crazy things on top of Linux, and older arches too (even used QEMU in a past life) What you want is a corner case, hence it would be on TODO, with the few of us left, living in fire-fighting mode is taking a lot of the time allotted. |
Description
When installing WINE under Debian on an amd64 machine, you usually need to pull i386 packages, too. However, the
pkg.installed
state seems to struggle with packages only available in foreign architectures, at least when you specify them without their architecture name.Setup
Steps to Reproduce the behavior
On an amd64 machine, try a state like this:
This will fail as follows:
The code in question is in
aptpkg.latest_version()
:As you can see, the
this_pkg
variable is set in theif
branch, but referenced in theelif
branch. This is at least brittle, if not outright wrong.The package causing this issue is
wine32
, since it doesn't exist in theamd64
architecture and thusapt-cache
prints its name with an architecture suffix:line.endswith(":") and line[:-1] in short_names
doesn't match that.salt-call pkg.latest_version wine32
is also broken, with the sameUnboundLocalError
.Changing the line in the YAML from
- wine32
to- wine32:i386
allows the state to apply cleanly.In contrast,
salt-call pkg.latest_version wine32:i386
still doesn't work.Expected behavior
Not quite sure actually. Maybe cut off the architecture suffix when parsing the
apt-cache
output? Or give a warning likepackage 'wine32' was not found, are you missing an architecture suffix (e.g. 'wine32:i386')?
?In any case, the parsing loop should be modified in order to not try and parse
Candidate:
lines whenthis_pkg
has not yet been set.Versions Report
salt --versions-report
The text was updated successfully, but these errors were encountered: