AUR/yay-bin and endeavouros/yay do not match

General system Pacman & AUR helpers
1

AUR/yay-bin-11.3.0-1-x86_64:
/usr/bin/yay sha1: b1166c4145eb194fd44e9c0a8a295b4ad311b07f

endeavouros/yay-11.3.0-1-x86_64:
/usr/bin/yay sha1: 69fd0c3d66cee201c31e16d2ee62e34cf3aa77a0

2

Why would they? They aren’t identical.

Two things:

  • Those packages aren’t identical
  • Even if they were, I don’t think that makepkg will always create reproducable builds. I believe it depends what you do in the PKGBUILD.
1 Like
3

AUR/yay-bin is pre-build and endeavouros/yay’s PKGBUILD just copy AUR/yay-bin

4

The package contains the metadata which is different. Also things like the directories can be different.

Even if the binaries are identical, the package won’t be.

1 Like
6

The problem is that binaries are identical

7

yeah if i rebuild the package the sha1sum is different from endeavour one but its also possible it is rebuilded mayby for some reason.

8

With the current build instructions/flags in the yay PKGBUILD you can’t expect reproducible builds anyways. The use of CGO might also play a role.

https://wiki.archlinux.org/title/Go_package_guidelines#Flags_and_build_options

f.e. -trimpath flag…

9

This is a rather pointless argument - If I have my compiler flags set differently than say, the person who built the aur binary, then I will get a different answer.

10

Did you read the comment in README? It seems pretty important.

Especially this part “Note: this PKGBUILD is currently not used.”

We are building yay from source.

3 Likes
11

Furthermore, gcc does not create reproducible builds. Of course, this does not apply to yay which is written in Golang, but I’m almost positive that Golang compiler also does not make reproducible builds.

12

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.