Arch Linux User Repository

@Sainan Providing and depending on sonames adds tooling to the packages that automatically tracks the library versions and makes sure they are compatible with things that depend on them so the package manager knows if a package can be upgraded without breaking or when things need to be recompiled against a new library version.

It isn't a crime that you don't understand the ins and outs of Arch Linux packaging since you're not even an Arch user, but it is pretty rude to continually insist evenything is fine when folks are contributing things that make it better for a system they do understand.

Are you just making up problems at this point? From what I understand, 'provides' merely serves as an alias for the package name. It is perfectly possible to use libpluto.so by simply adding 'plutolang' to 'depends'.

Besides the previously discussed issues which remain unfixed (improper job handling, not passing distro CXXFLAGS, etc., the v0.9.0 release also has a new problem in that it does not provide the soname and also does not include the checksums for the Git commit (this is new it current pacman tooling, but it is evident this was not properly updated with updpkgsums) after bumping the version).

For anybody that wants a cleaned up version that can also be compared with the VCS package, apply this patch with git am < file.patch (make sure it has a trailing blank line if you copy it from here):

From 5053d9b7637cb221a3a1a2dc96c889267bd8cbff Mon Sep 17 00:00:00 2001
From: Caleb Maclennan <caleb@alerque.com>
Date: Sat, 6 Apr 2024 15:07:56 +0300
Subject: [PATCH] Overhaul packaging with sodeps, etc.

Signed-off-by: Caleb Maclennan <caleb@alerque.com>
---
 .SRCINFO | 10 ++++++----
 PKGBUILD | 45 ++++++++++++++++++---------------------------
 2 files changed, 24 insertions(+), 31 deletions(-)

diff --git a/.SRCINFO b/.SRCINFO
index 0bdfa4f..a1debc8 100644
--- a/.SRCINFO
+++ b/.SRCINFO
@@ -1,16 +1,18 @@
 pkgbase = plutolang
    pkgdesc = A superset of Lua 5.4 — with unique features, optimizations, and improvements.
    pkgver = 0.9.0
-   pkgrel = 1
+   pkgrel = 1.1
    url = https://github.com/PlutoLang/Pluto
    arch = x86_64
    license = MIT
    makedepends = git
-   depends = glibc
    depends = gcc-libs
+   depends = glibc
    depends = readline
+   depends = libreadline.so
+   provides = libpluto.so
    conflicts = pluto
-   source = pluto-git::git+https://github.com/PlutoLang/Pluto#tag=0.9.0
-   sha256sums = SKIP
+   source = plutolang-git::git+https://github.com/PlutoLang/Pluto.git#tag=0.9.0
+   sha256sums = 254d5f3cda67bfb3e4c4ca343a1381787023b2464c8560d7c8cadeb65c33d518

 pkgname = plutolang
diff --git a/PKGBUILD b/PKGBUILD
index 8916e2a..7e6e9da 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -1,40 +1,31 @@
 # Maintainer: Sainan <sainan@calamity.gg>
+# Contributor: Caleb Maclennan <caleb@alerque.com>
+
 pkgname=plutolang
-pkgdesc="A superset of Lua 5.4 — with unique features, optimizations, and improvements."
 pkgver=0.9.0
-pkgrel=1
+pkgrel=1.1
+pkgdesc='A superset of Lua 5.4 — with unique features, optimizations, and improvements.'
+arch=(x86_64)
 url='https://github.com/PlutoLang/Pluto'
-arch=('x86_64')
 license=(MIT)
+depends=(gcc-libs
+         glibc
+         readline libreadline.so)
 makedepends=(git)
-depends=(glibc gcc-libs readline)
+provides=(libpluto.so)
 conflicts=(pluto)
-source=("pluto-git::git+https://github.com/PlutoLang/Pluto#tag=$pkgver")
-sha256sums=('SKIP')
+source=("$pkgname-git::git+$url.git#tag=$pkgver")
+sha256sums=('254d5f3cda67bfb3e4c4ca343a1381787023b2464c8560d7c8cadeb65c33d518')

 build () {
-   cd pluto-git/src
-   make -j PLAT=linux-readline
+   cd "$pkgname-git"
+   make MYCFLAGS="$CXXFLAGS -fPIC" MYLDFLAGS="$LDFLAGS"  PLAT=linux-readline
 }

 package () {
-   cd pluto-git
-
-   mkdir -p $pkgdir/usr/bin
-   cp src/pluto $pkgdir/usr/bin/pluto
-   cp src/plutoc $pkgdir/usr/bin/plutoc
-
-   mkdir -p $pkgdir/usr/lib
-   #cp src/libplutostatic.a $pkgdir/usr/lib/libplutostatic.a
-   cp src/libpluto.so $pkgdir/usr/lib/libpluto.so
-
-   mkdir -p $pkgdir/usr/include/pluto
-   cp src/lua.h $pkgdir/usr/include/pluto/lua.h
-   cp src/lua.hpp $pkgdir/usr/include/pluto/lua.hpp
-   cp src/lualib.h $pkgdir/usr/include/pluto/lualib.h
-   cp src/lauxlib.h $pkgdir/usr/include/pluto/lauxlib.h
-   cp src/luaconf.h $pkgdir/usr/include/pluto/luaconf.h
-
-   mkdir -p $pkgdir/usr/share/licenses/$pkgname/
-   cp LICENSE $pkgdir/usr/share/licenses/$pkgname/
+   cd "$pkgname-git"
+   install -Dm0755 -t "$pkgdir/usr/bin/" src/{pluto,plutoc}
+   install -Dm0755 -t "$pkgdir/usr/lib/" src/libpluto.so
+   install -Dm0644 -t "$pkgdir/usr/include/pluto/" src/lua.{h,hpp} src/{lualib,luaconf,lauxlib}.h
+   install -Dm0644 -t "$pkgdir/usr/share/licenses/$pkgname/" LICENSE
 }
-- 
2.44.0

Again, your initial fix was way too big, way too broad, and made some obviously-unacceptable changes. I do not mind contributions in general, but I do mind when it's coming from a place of no discipline.

No it did not. We're 90% of the way to where I tried to get you to in the first place with a patch and some notes, you've just made me rehash half of the guidelines found in the wiki here to convince you. I saw you were new to Arch and evidently had no idea what needed to be in the package; but I did not insult you at all (as you have done to me repeatedly) and decided to help out rather than just criticize this as a broken package. I package hundreds of projects for official Arch Linux repos and hundreds more here in the AUR and am quite familiar with many packaging issues. Rather than accusing me of having "no discipline" maybe you should have taken a moment to search the wiki for the things I mentioned.

Anyway, the reason for the -j flag is that the build should be parallelised to make it faster. This clearly does not seem to be the default when I use makepkg without specifying -j explicitly. Furthermore, specifying the -j flag does not seem to slow down the build when installing it via yay.

As I explained already, this is incorrect usage. Enabling parallel builds is the job of makepkg.conf (either at system or user level). It should not be used in a package to set a number of jobs because different hardware and sofware configurations will want a different maximum number of threads. You overriding the tooling settings with a forced unlimited threads is the PKGBUILD is not appropriate. The only time it should be used is for -j1 to turn off parallel builds for known-broken upstream projects with race conditions in their builds.

Again, your initial fix was way too big, way too broad, and made some obviously-unacceptable changes. I do not mind contributions in general, but I do mind when it's coming from a place of no discipline.

Anyway, the reason for the -j flag is that the build should be parallelised to make it faster. This clearly does not seem to be the default when I use makepkg without specifying -j explicitly. Furthermore, specifying the -j flag does not seem to slow down the build when installing it via yay.

Thanks for the hint about readline. I wasn't aware that the arrow keys were not working.

And you didn't believe me when I ⓐ sent you a fix and ⓑ specifically mentioned it was broken. Your response even after those two steps was "it absolutely works". This attitude of assuming contributors are just wrong until they argue and fight and explain in detail makes it kind of unfriendly to contribute towards your projects.

Thanks for fixing. If you take it one step farther like I did in plutolang-git by specifying the depends=(readline libreadline.so) then Arch will log with SO version the package is built against and warn the user before they try to install a different readline version rather than finding out it just crashes afterwards because of an SO version mismatch. Readline doesn't update frequently so this isn't a big deal, but if you want a really quality package the way that it would be in the official repos that's how you should record it.

The conflict thing seems like a bit of a nitpick, but I guess it's technically better for us to specify this.

Yes. With that line a package manager will be able to provide people the correct error message if they ever try to install both packages.

Afaik, PIC only matters for shared objects. I also don't know what "expected properties" you mean. It's possible these should rather be put into Pluto's actual Makefile rather than try to bandaid it by passing these flags.

This is part of making FULL_RELRO work for these (and other Lua project derived) binaries. Different distros and use cases will have different requirements as far as build flags go. What you prefer to set by default upstream as far as compiler security and features flags is up to you, but passing the distribution preferences in as a starting point and only overriding ones upstream that matter for some specific reason to the project is the best way to handle it. In this case Arch requires a number of security and feature flags, and for the most part namcap on the generated package will show when the generated binaries are not living up to the expectations. That doesn't necessarily mean those flags should be set upstream because different distros will have their own defaults and support for different features. Also their compiler versions will differ.

Also I'm not sure what you mean by -j not being needed, at least it does look like makepkg needs it.

Per the wiki the only reason to use -j in your build is to disable parallel execution for upstream projects where it is known broken. This is not the case for Lua or Pluto, both of which seem to build fine with parallel jobs. The place to set the jobs if you want to override the defaults is in makepkg.conf. Otherwise leave it alone by not using the flag at all and let other users makepkg defaults get used. In this case if there is something I'm missing and the Pluto build can cause a race condition then you should probably note that upstream and either fix it or force it to not be parallel.

Thanks for the hint about readline. I wasn't aware that the arrow keys were not working.

The conflict thing seems like a bit of a nitpick, but I guess it's technically better for us to specify this.

Afaik, PIC only matters for shared objects. I also don't know what "expected properties" you mean. It's possible these should rather be put into Pluto's actual Makefile rather than try to bandaid it by passing these flags.

Also I'm not sure what you mean by -j not being needed, at least it does look like makepkg needs it.

You can think it is "asinine" that a dependency required to build (but not run) a package and is not part of base-devel needs to be specified makedepends, but you don't make the rules. Even I as a packager building Arch Linux for official repos don't get to make up those rules. Personally I think it seems to make some sense the way it is, but if you want to suggest adding git as a dependency to base-devel that would change this situation, but at this point it isn't.

Almost all Arch Linux machines will have readline installed (because it is a dependency for bash as well as many other commonly used packages like util-linux, sqlite, rlwrap, etc.). Notably it is also used by the official lua packages. However it ends up not being used by this package because the linux target explicitly does not link it, while linux-readline does. Since almost everybody has the package already and all the official lua variants use it by default, it makes sense to use it here. Otherwise as it stands the REPL starts up but does not function as people might expect: notable arrow keys cannot be used to get back to previous lines of code and other editing bindings they might expect don't work.

Also you've fixed a number of other issues I've mentioned, but a couple are still missing:

• this could still use a conflicts=(pluto) line since there is a bin name clash between packages.
• you need to explicitly pass through the CXXFLAGS and LDFLAGS to the build file because it isn't reading the environment variables setup by the arch build tooling and hence the resulting binaries don't have the expected properties. Besides passing through the Arch defaults you'll also want to add -fPIC. You can do this with MYCFLAGS="$CXXFLAGS -fPIC" MYLDFLAGS="$LDFLAGS" linux-readline.
• you don't need the -j as it is setup by the Arch linux package builder configuration.

It is a bit asinine that I can define the source to be a Git repo, but must then also declare that Git is a build dependency. Nevertheless, I shall "fix" it.

Also, the REPL absolutely works without readline if you use make PLAT=linux instead of make PLAT=linux-readline.

Unable to point out specific issues? Dude seriously, I wrote a patch full of specific issues. And the Wiki packaging guidelines detail reasoning for the majority of my changes there. Since you can't be bothered to read and apparently you think I'm making things up here are some cliff notes:

You say it isn't broken, but it only builds because you installed things on your host system that you didn't declare in the dependencies. That makes it broken.

As one example, makedepends=(git) is absolutely required for this package. The REPL interface also doesn't work correctly without depends=(readline). Not packaging the license file for MIT licenses is incorrect. There are more things in my patch that correctly fix legitimate issues, some outright broken some just improvements that are valid in the Arch package landscape (like the conflicts declaration).

If you still don't believe me run namcap on the package you generated from makepkg, it will point out 4 warnings and 3 errors, only one of which are even things that I mentioned above so far.