Arch Linux User Repository

@blurgy Hey there, sure thing it's done. Please tell me if I missed something. (There's no need to duplicate messages between here and the lib32 though. :) )

Hello, please change the command ninja install -C build to ninja -C build install in the package() function. For people using ninja-samurai (it supports SAMUFLAGS variable to set jobs), it seems that the -C option must be supplied right after ninja. Thanks!

Please change the installation directory from /usr as this directory is on the blacklist in Proton above version 5.13.

@gee: I still think you're missing something. Whether the PKGBUILD is split or not does not change the packages themselves. The dependencies will not change, there's no transition at all. Since they won't change, you could split them apart with no pkgrel() bump because the build process did not change.

@yochananmarqos: yeah I'm more nuanced about this than you... I understand your point, and live by it to an extent, but I don't want to break functionality and waste users' time if it can be prevented. Of course, this is also AUR, not quite the best place for people that don't want to read.

So what I think I'll do is either: - give it about a week and do it, and add a note in the post-install step for 64b. - do it right away but make the dependencies circular for a week or so before removing that.

Since I'd rather not do extra work, I'll probably go with the first. Anyway, we've both spent too much time on this topic already, it is not worth it. :)

Yeah, I still think makepkg should support split package for archs, if not it's just full of redundant stuff for no reason...

@gee: We're package maintainers, not hand-holders. It's not up to use to write them a tutorial. That's what the upstream README is for. All the other lib32- packages in the Arch repos are separate packages.

I originally thought it would be easier to maintain as a split package since mangohud-git was, but you helped me realize it's not the greatest idea in the world to mix different architecture packages together.

@yochananmarqos: Hmmm I am not sure we are talking about the same thing. What I mean is that if I split this vkBasalt page (/PKGBUILD) from being a single package to having the 32b on a different page (/PKGBUILD), I'm afraid some people will see not understand why things don't work with 32b games anymore unless they manually grab the 32b PKGBUILD too. I'm talking about a single package because some people may have not yet grabbed the 32/64b package split yet, which is transparent indeed, and which is what I'm hoping will allow a smoother transition if given time.

@gee: Again, the split package is transparent. They'll still see the update no matter if the packages are split or not.

@yochananmarqos: Sad :/ I guess I'll wait a little bit for people to get the current update that'll give them the 32b before doing the proper split then which hopefully should be straightforward then.

Thank you for your help!

@gee: No, they'll only appear together when they're part of a split package. Other than this page, split packages are normally transparent to the user, anyway. Just list vkbasalt as a dependency of lib32-vkbasalt as is common for packages like these.