[PATCH 1/2] Makefile: Install Lua in `exec` stage, not `data`

[PATCH 1/2] Makefile: Install Lua in `exec` stage, not `data`

[Valters Jansons]

Automake installation has two stages:
* `exec` for platform-specific files,
* `data` for platform-agnostic files.

Automake separates the install stages based on the directory (target)
variable name. Built-in targets have known stages. Any custom-defined
ones check simply whether the target name contains `exec` substring.

Currently, the Lua module is installed in the `data` stage, because
`lua` is not considered an `exec` stage name. However, the Lua module
contains C code (it is architecture-specific).

Similar to how Python is installed via `pyexec`, Lua should be
installed via `luaexec`. That way Automake splits it into `exec` stage
correctly.

Internally, the installation target directory is `LUA_INSTALL_CMOD`
which also signals that this is a platform/architecture-specific
installation. This logic remains unchanged, and the Lua `.so` gets
installed to the same target as a result.

This change is also important to allow libtool cleanup to be done in
`install-exec-hook` consistently. Without this change, part of la-files
cleanup would need to be moved to `install-data-hook`.

Ref: https://www.gnu.org/software/automake/manual/html_node/The-Two-Parts-of-Install.html

Signed-off-by: Valters Jansons <valter.jansons@gmail.com>
---
 Makefile.am | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index c5b8df3..a64a20a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -230,10 +230,10 @@ src_python__location_la_LIBADD = \
 # ------------------------------------------------------------------------------
 
 if ENABLE_LUA
-lua_LTLIBRARIES = \
+luaexec_LTLIBRARIES = \
 	src/lua/location.la
 
-luadir = $(LUA_INSTALL_CMOD)
+luaexecdir = $(LUA_INSTALL_CMOD)
 
 src_lua_location_la_SOURCES = \
 	src/lua/as.c \
-- 
2.54.0

[PATCH 2/2] Makefile: Avoid installing libtool control files

[Valters Jansons]

This project currently uses autoconf, automake, and libtool for
building. During build process, libtool creates `.la` control files
with metadata about the `.so` library. On modern systems, shipping
these files is now strongly discouraged.

The `.la` files are generally not used on live systems. The only
scenario where they would be used is if someone loads the library using
libltdl (libtool's `dlopen` wrapper). However, both Python and Lua just
load the library directly using a `dlopen("location.so")` instead of
calling `lt_dlopen("location.la")`. This project does not reference
`lt_dlopen` or `ltdl` as such.

Moreover, the `.la` files include redundant dependency chain
information. For example, the Lua module depends on libloc. Even though
OpenSSL is a transitive dependency (`src/database.c` and `src/writer.c`,
not `src/lua/`), libtool anyway adds `-lssl` (as well as `-lcrypto
-lresolv`) directly to `dependency_libs` of Lua's `location.la`.
Listing these transitive dependencies muddies the chain. If someone is
consuming the Lua module downstream, then libtool would force the full
dependency chain onto them directly, which is not needed.

Additionally, due to hardcoded dependencies, rebuild propagation is
a concern. An upstream library updating their soname requires all
downstream `.la` files to be rebuilt, even if libloc's ABI has not
changed. This is especially painful at distro packaging scale.

As a result, modern packaging is pushing towards removing these `.la`
files. In cases where some libltdl consumers exist, the fallback route
is emptying out the dependency_libs metadata field. This is visible in
Debian Lintian as error `non-empty-dependency_libs-in-la-file`.

We can go the whole way and drop these files outright. The `.la` files
reference each other; therefore, when one is being removed, all of them
should be removed, to avoid dangling references.

Ref: https://wiki.debian.org/ReleaseGoals/LAFileRemoval
Ref: https://fedoraproject.org/wiki/Changes/RemoveLaFiles

Signed-off-by: Valters Jansons <valter.jansons@gmail.com>
---
Note: This commit adds the removal logic in `install-exec-hook`. This
depends on the parent commit in this series, ensuring Lua is installed
in `exec` instead of `data`.

 Makefile.am | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index a64a20a..735e07a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -359,6 +359,20 @@ CLEANFILES += \
 
 # ------------------------------------------------------------------------------
 
+install-exec-hook:
+	# Avoid installing .la files, as we do not use libltdl.
+	@for la in $(lib_LTLIBRARIES); do \
+	  rm -f "$(DESTDIR)$(libdir)/`basename $$la`"; \
+	done
+	@for la in $(pyexec_LTLIBRARIES); do \
+	  rm -f "$(DESTDIR)$(pyexecdir)/`basename $$la`"; \
+	done
+	@for la in $(luaexec_LTLIBRARIES); do \
+	  rm -f "$(DESTDIR)$(luaexecdir)/`basename $$la`"; \
+	done
+
+# ------------------------------------------------------------------------------
+
 # Use systemd timers if available
 if HAVE_SYSTEMD
 systemdsystemunit_DATA = \
-- 
2.54.0

[PATCH 2/2] [v2] Makefile: Avoid installing libtool control files

[Valters Jansons]

This project currently uses autoconf, automake, and libtool for
building. During build process, libtool creates `.la` control files
with metadata about the `.so` library. On modern systems, shipping
these files is now strongly discouraged.

The `.la` files are generally not used on live systems. The only
scenario where they would be used is if someone loads the library using
libltdl (libtool's `dlopen` wrapper). However, both Python and Lua just
load the library directly using a `dlopen("location.so")` instead of
calling `lt_dlopen("location.la")`. This project does not reference
`lt_dlopen` or `ltdl` as such.

Moreover, the `.la` files include redundant dependency chain
information. For example, the Lua module depends on libloc. Even though
OpenSSL is a transitive dependency (`src/database.c` and `src/writer.c`,
not `src/lua/`), libtool anyway adds `-lssl` (as well as `-lcrypto
-lresolv`) directly to `dependency_libs` of Lua's `location.la`.
Listing these transitive dependencies muddies the chain. If someone is
consuming the Lua module downstream, then libtool would force the full
dependency chain onto them directly, which is not needed.

Additionally, due to hardcoded dependencies, rebuild propagation is
a concern. An upstream library updating their soname requires all
downstream `.la` files to be rebuilt, even if libloc's ABI has not
changed. This is especially painful at distro packaging scale.

As a result, modern packaging is pushing towards removing these `.la`
files. In cases where some libltdl consumers exist, the fallback route
is emptying out the dependency_libs metadata field. This is visible in
Debian Lintian as error `non-empty-dependency_libs-in-la-file`.

We can go the whole way and drop these files outright. The `.la` files
reference each other; therefore, when one is being removed, all of them
should be removed, to avoid dangling references.

Ref: https://wiki.debian.org/ReleaseGoals/LAFileRemoval
Ref: https://fedoraproject.org/wiki/Changes/RemoveLaFiles

Signed-off-by: Valters Jansons <valter.jansons@gmail.com>
---
Note: This commit adds the removal logic in `install-exec-hook`. This
depends on the parent commit in this series, ensuring Lua is installed
in `exec` instead of `data`.

Apologies on the previous commit version having a mis-aligned comment.
A rule cannot have a # line right there. This version patches that.

 Makefile.am | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index a64a20a..93c5aad 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -359,6 +359,20 @@ CLEANFILES += \
 
 # ------------------------------------------------------------------------------
 
+# Avoid installing .la files, as we do not use libltdl.
+install-exec-hook:
+	@for la in $(lib_LTLIBRARIES); do \
+	  rm -f "$(DESTDIR)$(libdir)/`basename $$la`"; \
+	done
+	@for la in $(pyexec_LTLIBRARIES); do \
+	  rm -f "$(DESTDIR)$(pyexecdir)/`basename $$la`"; \
+	done
+	@for la in $(luaexec_LTLIBRARIES); do \
+	  rm -f "$(DESTDIR)$(luaexecdir)/`basename $$la`"; \
+	done
+
+# ------------------------------------------------------------------------------
+
 # Use systemd timers if available
 if HAVE_SYSTEMD
 systemdsystemunit_DATA = \
-- 
2.54.0