[Luciogi]

Testing the changes

• I tested the changes in this PR: YES

Local build testing

• I built this PR locally for my native architecture, (X86_64-GLIBC)

[Duncaen]

Why is the duckdb change in this PR and why is it needed?

[Duncaen]

Also don't really like calling make from pkg_install functions, the normal practice is to do this in steps, the intsall step is installing things into destdir and then the the package step splits sub packages.

[Luciogi]

Why is the duckdb change in this PR and why is it needed?

hook 04-generate-runtime-deps was failing as it could not found libduckdb.so in common/shlibs

previously libduckdb.so was packaged in duckdb-devel, but in shlibs file, i could not any instance where -devel package was added.

duckdb does not have .so file like other package haves libduckdb.so.4

[Luciogi]

Also don't really like calling make from pkg_install functions, the normal practice is to do this in steps, the intsall step is installing things into destdir and then the the package step splits sub packages.

If I recall correctly, after running `do_build()` it was producing object file in `/masterdir/buildir/lua54-luadbi-0.7.5/lua*/build/`

I may need to recheck.

[Duncaen]

Also don't really see the reason for the _lua_vers array, especially with things like:

	for ver in ${_lua_vers[@]:1}; do
		cp -a lua51 "lua${ver/./}"
	done

this is just horrible to read, either just keep the 3 cp lines or make it a loop a the list in the format it needs, without extra global variables.

Seems useless to introduce all this magic just to add a new lua version every few years, especially because it always needs extra work to setup the subpackages anyways.