Rebuild option is ignored

[marcin-rzeznicki]

Affected Version

yay v12.0.4 - libalpm v13.0.2

Describe the bug

Yay does not rebuild AUR packages, even though it is explicitly asked to via --rebuild e.g.

❯ yay -S autojump --rebuild
... blah blah ...
-> autojump-22.5.3-9 already made -- skipping build

Judging by the debug output, this is caused here ->

yay/aur_install.go

Lines 286 to 299 in f7731d7

	switch {
	case needed && installer.pkgsAreAlreadyInstalled(pkgdests, pkgVersion) || installer.downloadOnly:
	args = []string{"-c", "--nobuild", "--noextract", "--ignorearch"}
	pkgdests = map[string]string{}
	text.Warnln(gotext.Get("%s is up to date -- skipping", text.Cyan(base+"-"+pkgVersion)))
	case pkgsAreBuilt(pkgdests):
	args = []string{"-c", "--nobuild", "--noextract", "--ignorearch"}
	text.Warnln(gotext.Get("%s already made -- skipping build", text.Cyan(base+"-"+pkgVersion)))
	default:
	args = []string{"-cf", "--noconfirm", "--noextract", "--noprepare", "--holdver"}
	if installIncompatible {
	args = append(args, "--ignorearch")
	}
	}

- there is no check for the rebuild option in sight, only if the file exists.

Expected behavior

--rebuild should always REBUILD AUR packages.

Output

{
"aururl": "https://aur.archlinux.org",
"aurrpcurl": "https://aur.archlinux.org/rpc?",
"buildDir": "/var/local/build",
"editor": "",
"editorflags": "",
"makepkgbin": "makepkg",
"makepkgconf": "",
"pacmanbin": "pacman",
"pacmanconf": "/etc/pacman.conf",
"redownload": "no",
"rebuild": "no",
"answerclean": "",
"answerdiff": "",
"answeredit": "",
"answerupgrade": "",
"gitbin": "git",
"gpgbin": "gpg",
"gpgflags": "",
"mflags": "",
"sortby": "votes",
"searchby": "name-desc",
"gitflags": "",
"removemake": "ask",
"sudobin": "sudo",
"sudoflags": "",
"version": "12.0.4",
"requestsplitn": 150,
"completionrefreshtime": 7,
"maxconcurrentdownloads": 1,
"bottomup": true,
"sudoloop": false,
"timeupdate": false,
"devel": true,
"cleanAfter": false,
"provides": false,
"pgpfetch": true,
"upgrademenu": true,
"cleanmenu": true,
"diffmenu": true,
"editmenu": true,
"combinedupgrade": false,
"useask": true,
"batchinstall": false,
"singlelineresults": false,
"separatesources": true,
"newinstallengine": true,
"debug": false,
"rpc": true,
"doubleconfirm": true
}

[bulletmark]

Yes, I also have seen this bug today on my various Arch systems. Very noticeable on Arch with today's new python 3.11 update so everybody wants to do yay -S --rebuild --noconfirm $(yay -Qqo /usr/lib/python3.10/) but it fails to force the update.

[marcin-rzeznicki]

@bulletmark exactly my case 😃

[evertvorster]

My case too, I am getting segfaults all over the place, and want to be rebuilding stuff. Just incidentally, also affected are --rebuildall and --rebuildtree

[Jguer]

Haven't confirmed but believe the reports

Workaround for now, change your ~/.config/yay/config.json to

{
  "newinstallengine": false
}

@evertvorster can you share those tracebacks?

[marcin-rzeznicki]

Perhaps a simpler workaround would be (judging by the code) to simply remove packages you're about to rebuild from $PKGDEST

[evertvorster]

In regards to the segfaults, most notably it was pipewire-manager that segfaulted on system startup, and then keepassxc that segfaulted when trying to connect to browsers. I compiled keepassxc from git, and then that was fine, and swapped pipewire-manager for pipewire-session... So I am not seeing segfaults anymore.
The other interesting segfault was in gcc 13 when compiling glaxnimate-git, so I downgraded gcc for now until a new version comes out. ;)
Unfortunately I did not feel up to the task of manually running those processes in gdb just to get a backtrace, and getting a debug build of gcc seemed even more daunting.

In regards with the rebuild option being ignored, I just went into the aur directory of each package on the list and issued a makepkg -fi
It solved the problem I was having, and I am patiently awaiting a fix that would allow yay to respect the --rebuild option again.

My system information:

Operating System: Arch Linux 
KDE Plasma Version: 5.27.4
KDE Frameworks Version: 5.105.0
Qt Version: 5.15.9
Kernel Version: 6.3.1-AMD-znver2 (64-bit)
Graphics Platform: Wayland
Processors: 8 × AMD Ryzen 7 4700U with Radeon Graphics
Memory: 36.9 GiB of RAM
Graphics Processor: AMD Radeon Graphics
Manufacturer: LENOVO
Product Name: 20T8001JUS
System Version: ThinkPad E15 Gen 2

[marcin-rzeznicki]

@evertvorster I believe that author understood your sentence that "I am getting segfaults all over the place (...)" so that yay is segfaulting 😄

[bulletmark]

Given the slow resolution of this bug I just discovered that instead of the currently problematic:

yay -S --rebuild --noconfirm $(yay -Qqo /usr/lib/python3.10/) 

you can use instead:

yay -S --answerclean=All --noconfirm $(yay -Qoq /usr/lib/python3.10)

That means I can stop having to recommend paru which I had been forced to do since this bug was identified.

[yochananmarqos]

@bulletmark That makes no difference. If the existing version is in the cache, it will still reinstall it instead of replacing it with the rebuilt package.

[bulletmark]

@yochananmarqos obviously I tried that before I posted here. You try it and you will see that the package gets rebuilt.

[yochananmarqos]

@bulletmark I tried both as well as attempting to combine the two options. I tested this after updating to Python 3.11. After running yay -S $(pacman -Qoq /usr/lib/python3.10) --answerclean All, I ran pacman -Qoq /usr/lib/python3.10 and there were still packages with files in that directory.

The point is not that it rebuilds the package or not. It reinstalls the cached package regardless.

[bulletmark]

@yochananmarqos maybe you are right but what cached package could it reinstall? If the package gets rebuilt then the only "cached" file is the one in e.g. ~/.cache/yay/package/package-version.pkg.tar.zst which is the one that gets reinstalled. I think that package-version is up to date -- reinstalling message is just warning that the same version number is being reinstalled. Just test this for any one existing python AUR package, no need to test against something still using python 3.10. You can see the cached file definitely gets rebuilt and gets a new time-stamp. Are you sure your python3.10 files you mention are not from somewhere else (e.g. a manual pip install you previously did)?

[yochananmarqos]

Are you sure your python3.10 files you mention are not from somewhere else (e.g. a manual pip install you previously did)?

100% certain. I do not use Pip at all.

I ended up using paru -S $(pacman -Qoq /usr/lib/python3.10) --rebuild to successfully rebuild the packages with nothing remaining in the 3.10 folder.

[Jguer]

Haven't had the time to work on this lately, if someone wants to try their hand at it I'll be happy to review it

[smolx]

@Jguer , I took a quick look at the issue and was able to fix --rebuild option. But fixing of --rebuildtree requires much more effort and therefore time. And I'm not even talking about --rebuildall option. If I understand correctly, it isn't implemented even in the "old engine".

Would a --rebuild fix be enough for a PR?

[Jguer]

Would a --rebuild fix be enough for a PR?

I think so if it's not too cumbersome to implement and test.
In the 'new engine' I didn't bother a lot with --rebuild* as it was already very unmaintained/untested

[smolx]

It makes sense to create a new issue for --rebuildtree and --rebuildall options. They are still not implemented in the "new engine".

[marcin-rzeznicki]

Thank you.