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 Installer constructor clones them from the current config.mflags). However, the CLI argument parser does not update config.mflags on --nocheck, and only sets config.no_check = true.
The config.mflags are only updated after the construction of the Chroot object (specifically, in build_pkgbuilds → installer.install → self.resolve_targets → resolver::flags), at which point changes to config.mflags do not propagate to the copy held by the Chroot object (which is what is used when running makepkg).
Fix
I think that the easiest way to fix this would be to hold the mflags in a single shared reference (Rc or Arc) so that updates to it from anywhere will propagate out to all other objects. Another (possibly more robust) option would be to make the build system more modular such that cloning these configurations is never even necessary, although I suspect that this would be a lot more work.
The text was updated successfully, but these errors were encountered:
Affected Version
67cc6f4 (and earlier)
Description
The
mflags
passed tomakechrootpkg
are determined atparu/src/install.rs
Line 99 in 67cc6f4
Installer
constructor clones them from the currentconfig.mflags
). However, the CLI argument parser does not updateconfig.mflags
on--nocheck
, and only setsconfig.no_check = true
.paru/src/command_line.rs
Line 252 in 67cc6f4
config.mflags
are only updated after the construction of theChroot
object (specifically, inbuild_pkgbuilds
→installer.install
→self.resolve_targets
→resolver::flags
), at which point changes toconfig.mflags
do not propagate to the copy held by theChroot
object (which is what is used when runningmakepkg
).Fix
I think that the easiest way to fix this would be to hold the
mflags
in a single shared reference (Rc
orArc
) so that updates to it from anywhere will propagate out to all other objects. Another (possibly more robust) option would be to make the build system more modular such that cloning these configurations is never even necessary, although I suspect that this would be a lot more work.The text was updated successfully, but these errors were encountered: