You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The change in 8bd32c2 introduces a regression where (at least on Gitlab) the right target cannot be find, and the first one that matches OS / ARCH is returned instead.
This introduces an issue when a release contains assets for both x86_64-unknown-linux-musl and x86_64-unknown-linux-gnu. Both contain linux and x86_64, so even though the first part of the if statement does not match, the second one always does.
If we really want a fallback to a less specific asset target when no specific one can be found, we should first check all assets to determine if one can be found. As it stands now, the check is short circuited because .find stops after the first match, which will most likely be the OS / ARCH check.
Personally I don't think the logic introduced in 8bd32c2 is positive in any way, because this also allows accidental upgrades to another target. For instance, if I'm self updating on an OS that only has musl (like Alpine), and the first entry found is x86_64-unknown-linux-gnu, the current logic will happily update to a binary that requires libc that cannot be run. This is bad, because the right target might be later in the list, or might be omitted intentionally for a specific version.
The text was updated successfully, but these errors were encountered:
For anyone else running into this issue, downgrading to [email protected] works in the mean time as that was the version before the logic above was introduced.
The change in 8bd32c2 introduces a regression where (at least on Gitlab) the right target cannot be find, and the first one that matches OS / ARCH is returned instead.
This introduces an issue when a release contains assets for both
x86_64-unknown-linux-musl
andx86_64-unknown-linux-gnu
. Both containlinux
andx86_64
, so even though the first part of the if statement does not match, the second one always does.If we really want a fallback to a less specific asset target when no specific one can be found, we should first check all assets to determine if one can be found. As it stands now, the check is short circuited because
.find
stops after the first match, which will most likely be the OS / ARCH check.Personally I don't think the logic introduced in 8bd32c2 is positive in any way, because this also allows accidental upgrades to another target. For instance, if I'm self updating on an OS that only has musl (like Alpine), and the first entry found is
x86_64-unknown-linux-gnu
, the current logic will happily update to a binary that requires libc that cannot be run. This is bad, because the right target might be later in the list, or might be omitted intentionally for a specific version.The text was updated successfully, but these errors were encountered: