Debian Patches
Status for libloc/0.9.19-1
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| non-empty-dependency_libs-in-la-file-1.patch | Makefile: Install Lua in `exec` stage, not `data` 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`. |
Valters Jansons <valter.jansons@gmail.com> | yes | other | 2026-06-24 | |
| non-empty-dependency_libs-in-la-file-2.patch | Makefile: Avoid installing libtool control files 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. |
Valters Jansons <valter.jansons@gmail.com> | yes | other | 2026-06-24 | |
| autotools-pkg-config-macro-not-cross-compilation-safe.patch | configure: Remove AC_PATH_PROG call for pkg-config We already use PKG_PROG_PKG_CONFIG macro higher up in configure.ac, and it populates PKG_CONFIG variable already. This AC_PATH_PROG use is redundant at best, and breaks cross-compilation support in specific cases. The legacy left-over is safe to drop. |
Valters Jansons <valter.jansons@gmail.com> | yes | other | 2026-06-24 |