let's reorganize and distribute it in the same way both in ELSE and here

[porres]

Hi, I see you are using pdlibbuilder and shipping the same things that I am in ELSE (the tutorial).

I am in fact reorganizing things a bit differently in my distribution because it is all too huge, hence I created a folder for all 'pdlua' files. In the general folder I only have the pdlua binary, the pd.lua file and the help files. I guess this makes sense for you distribution as well, because this is what you need in fact, the rest is "extra files", examples.

To illustrate, here's a screenshot on how I ship it and how it would be for you.

This would also make things easier for me as I do now have a separate folder that I copy myself and I wouldn't need it.

I can try and send you a PR soon

[agraef]

I have to say that I much prefer the way that it is now, where I just click on pdlua in the help browser and everything is just there. Instead I'll then have to click on pdlua once more to get to the examples. Which is tedious.

I don't argue that this kind of organization makes a lot of sense in the context of ELSE, the way you included pdlua there. But not so much over here where the external already goes into its own pdlua dir anyway.

I do understand the need to make the installation more flexible so that a sub-make install would do what you want/need in ELSE. But we need a solution that doesn't make things worse in pd-lua proper. ;-) I'll think about it.

[dvzrv]

Hm, so this now leading to /usr/lib/pd/extra/pdlua/pdlua/ in 0.11.0 is intended behavior?

[porres]

That’s not where you really want to put externals for quite a few years now. Better to use documents/pd/externals/pdlua no need for the extra pdlua

[dvzrv]

The default /usr/lib/pd-externals/pdlua/pdlua (if I don't set PDLIBDIR=/usr/lib/pd/extra) is supposed to be used for all pd installations on a system. That is not relevant for system packaging though (I'm maintaining pd etc. for Arch Linux) and even actively counterproductive, since it would apply for pd build for different architectures as well.

Back to my question though: Is the pdlua/pdlua (two dirs) intended now? If so, I can continue packaging :)

[agraef]

Yep, all the extra docs are in pdlua/pdlua now. I'll also have to fix up the AUR pd-lua-git package.

[agraef]

Hmm, @dvzrv, I think there's a misunderstanding. The external directory (pdlua) is still installed under whatever externals dir you use, not pdlua/pdlua (that's where the extra docs will end up in). Let me have a look at your PKGBUILD so that I can tell you exactly what needs to be done.

[agraef]

Concerning /usr/lib/pd-externals, yes that's outdated, I think that this was never actually in Pd's default hard-coded search paths for Linux, only /usr/local/lib/pd-externals (which is still supported, but of course you don't want to install into /usr/local in an official distro package). So we picked /usr/lib/pd-externals instead, but that's troublesome because it's not in Pd's search path by default, so the user will have to set it up him/herself.

The other search paths, including ~/Documents/Pd/externals which is for the benefit of Deken packages, are all in the user's homedir, which we can't install into either.

Maybe we should just patch up s_path.c in the Arch Pd package in order to add /usr/lib/pd-externals to the default search path? (I think we do that in purr-data, but I might be wrong about that.)

[agraef]

@dvzrv I just grabbed your PKGBUILD and here's my take. Things are a lot easier now that we use pd-lib-builder since it only installs what's needed, so the PKGBUILD can be simplified considerably. Note that I left out the developer docs in the pd-lua/doc folder in the source, which aren't installed any more and are for developers only anyway.

One might consider moving or copying the installed /usr/lib/pd-externals/pdlua/pdlua/tutorial/pd-lua-intro.pdf to /usr/share/doc/pd-lua, but I think that most Pd users would rather look for that under /usr/lib/pd-externals/pdlua/ anyway.

# Maintainer: David Runge <dvzrv@archlinux.org>

pkgname=pd-lua
pkgver=0.11.0
pkgrel=1
pkgdesc="LUA embedding for pd"
arch=(x86_64)
url="https://github.com/agraef/pd-lua"
license=(GPL2)
groups=(pd-externals pro-audio)
depends=(gcc-libs glibc lua pd)
source=($pkgname-$pkgver.tar.gz::https://github.com/agraef/$pkgname/archive/$pkgver.tar.gz)
sha512sums=('f726d126803bb4a26d1663dc2901205a7b9068135e3ab27db0aedec7ead5bf8066c3da1bbbc6252c2bab23d338e368c6614d9a3b525b37ed755a20182b794140')
b2sums=('bce1f38c65001d7d16a11f3d249dfa32c7f78c778918aada82f4ed8166315b10f965b221f26929d95aa2c2199bb38faa27435d53145fce34cb33d9da1876474b')

build() {
  make LDFLAGS="$LDFLAGS" CFLAGS="$CFLAGS" -C $pkgname-$pkgver
}

package() {
  cd $pkgname-$pkgver
  make DESTDIR="$pkgdir/" prefix=/usr install
  # docs
  install -vDm 644 README -t "$pkgdir/usr/share/doc/$pkgname/"
}

Diffs against the previous one:

--- PKGBUILD.orig       2023-01-10 00:41:49.567681380 +0100
+++ PKGBUILD    2023-01-10 00:51:29.371391418 +0100
@@ -1,7 +1,7 @@
 # Maintainer: David Runge <dvzrv@archlinux.org>

 pkgname=pd-lua
-pkgver=0.10.2
+pkgver=0.11.0
 pkgrel=1
 pkgdesc="LUA embedding for pd"
 arch=(x86_64)
@@ -10,13 +10,8 @@
 groups=(pd-externals pro-audio)
 depends=(gcc-libs glibc lua pd)
 source=($pkgname-$pkgver.tar.gz::https://github.com/agraef/$pkgname/archive/$pkgver.tar.gz)
-sha512sums=('0f61159bbb67c48ce379e4c1f7f1223004cc43065417e08a26d9ae40dd745ad01cc6c01921703a7118873055abc782eff0479713e187a61bd8edf2a98df72a30')
-b2sums=('605e01a7d76a9d01819c6133cb9a2976729ed233e02da71d48b63708b6c4bc3bc5fb2aa67ec1732ff00d7240033d78ef4505bf15e0e7e8f8a50568d374927ab4')
-
-prepare() {
-  # not installing license and README (to wrong location)
-  sed -e '/COPYING /d;/README /d' -i $pkgname-$pkgver/Makefile
-}
+sha512sums=('f726d126803bb4a26d1663dc2901205a7b9068135e3ab27db0aedec7ead5bf8066c3da1bbbc6252c2bab23d338e368c6614d9a3b525b37ed755a20182b794140')
+b2sums=('bce1f38c65001d7d16a11f3d249dfa32c7f78c778918aada82f4ed8166315b10f965b221f26929d95aa2c2199bb38faa27435d53145fce34cb33d9da1876474b')

 build() {
   make LDFLAGS="$LDFLAGS" CFLAGS="$CFLAGS" -C $pkgname-$pkgver
@@ -27,6 +22,4 @@
   make DESTDIR="$pkgdir/" prefix=/usr install
   # docs
   install -vDm 644 README -t "$pkgdir/usr/share/doc/$pkgname/"
-  mv -v "$pkgdir/usr/lib/pd/extra/pdlua/doc/"* "$pkgdir/usr/share/doc/$pkgname/"
-  rmdir -v "$pkgdir/usr/lib/pd/extra/pdlua/doc/"
 }

I'll modify the pd-lua-git package in the AUR accordingly.

[agraef]

AUR pd-lua-git is fixed now.

[dvzrv]

Maybe we should just patch up s_path.c in the Arch Pd package in order to add /usr/lib/pd-externals to the default search path? (I think we do that in purr-data, but I might be wrong about that.)

No. If pd does not support /usr/lib/pd-externals/ natively, then the pd-lua external (like all the other ones in the Arch Linux repositories) will go to /usr/lib/pd/extra/. I don't see a reason to use anything but the application-specific directory (as defined by upstream), if the global directory is tied to the use of /usr/local/ and I will not start patching this type of stuff in unless upstream adds the support themselves.

This seems to be rather an upstream definition problem and personally I lack the time to deal with figuring out what/why they would want to change that. Maybe as pd external developers you can start a discussion with them on that topic? Including /usr/lib/pd-externals/ would make sense I guess, but generally (as a distribution packager) I don't see much benefit using it over /usr/lib/pd/extra/.

[agraef]

No. If pd does not support /usr/lib/pd-externals/ natively, then the pd-lua external (like all the other ones in the Arch Linux repositories) will go to /usr/lib/pd/extra/.

Yes, I agree, this seems reasonable, I'll update pd-lua-git accordingly. I see that you've already updated the community package, thanks!