Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1272127 > unrolled thread

Bug#1121644: luanti-server: Add support for /usr/local/ for user provided content

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1121644: luanti-server: Add support for /usr/local/ for user provided content Chris Barry <chris@barry.im> - 2025-11-29 21:20 +0100
    Bug#1121644: luanti-server: Add support for /usr/local/ for user provided content Tobias Frost <tobi@debian.org> - 2026-02-01 12:30 +0100
      Bug#1121644: luanti-server: Add support for /usr/local/ for user provided content Simon McVittie <smcv@debian.org> - 2026-02-01 13:50 +0100

#1272127 — Bug#1121644: luanti-server: Add support for /usr/local/ for user provided content

Package: luanti-server
Version: 5.10.0+dfsg-5
Severity: wishlist
X-Debbugs-Cc: chris@barry.im

Dear Maintainer,

In order to ensure a clean separation between debian provided games/mods and user provided games/modes, I suggest the following:

- User provided /usr/local/share/luanti/{games,mods}
- Debian provided /usr/share/luanti/{games,mods} 

I have this working locally by updating environment variables as follows in a systemd dropin file. These could be added to the provided systemd service files.

```
Environment=MINETEST_MOD_PATH=/usr/local/share/luanti/mods/:/usr/share/luanti/mods/
Environment=MINETEST_GAME_PATH=/usr/local/share/luanti/games/:/usr/share/luanti/games/
```

There should be considerations for the existing MINETEST_MOD_PATH since it currently uses the old name minetest (i.e. /usr/share/games/minetest/mods)

This will help server operators use debian provided packages when available while still being able to bring in their own custom modifications

-- System Information:
Debian Release: 13.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.12.48+deb13-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages luanti-server depends on:
ii  libc6                      2.41-12
ii  libcurl4t64                8.14.1-2+deb13u2
ii  libgcc-s1                  14.2.0-19
ii  libgmp10                   2:6.3.0+dfsg-3
ii  libjsoncpp26               1.9.6-3
ii  libleveldb1d               1.23-5+b2
ii  libluajit-5.1-2            2.1.0+openresty20250117-2
ii  libpq5                     17.6-0+deb13u1
ii  libprometheus-cpp-core1.0  1.0.2-2+b3
ii  libprometheus-cpp-pull1.0  1.0.2-2+b3
ii  libspatialindex8           2.1.0-1
ii  libsqlite3-0               3.46.1-7
ii  libstdc++6                 14.2.0-19
ii  libzstd1                   1.5.7+dfsg-1
ii  luanti-data                5.10.0+dfsg-5
ii  luanti-game-minetest       5.8.0.40.gc7be7c1-3
ii  zlib1g                     1:1.3.dfsg+really1.3.1-1+b1

luanti-server recommends no packages.

luanti-server suggests no packages.

-- Configuration Files:
/etc/luanti/default.conf changed [not included]

-- no debconf information

[toc] | [next] | [standalone]

#1280395

Package: luanti-server
Followup-For: Bug #1121644
Control: tags -1 wontfix
Control: close -1

Hi Chris,

Hi,

thanks for the suggestion.

> In order to ensure a clean separation between debian provided games/mods and user provided games/modes, I suggest the following:
>
> * User provided /usr/local/share/luanti/{games,mods}
> * Debian provided /usr/share/luanti/{games,mods}

I agree with the goal of clearly separating Debian-managed content from
locally provided mods and games. However, using /usr/local as a
supported search path in the Debian package is problematic from a policy
perspective.

According to the Filesystem Hierarchy Standard and Debian Policy,
/usr/local is reserved exclusively for software and data installed by
the local administrator and must remain outside the scope of Debian
packages. While Debian packages must not install files into /usr/local,
they also should not define /usr/local as part of their intended runtime
behaviour or interface. Adding /usr/local/share/luanti to the default
search paths would effectively make /usr/local a supported extension
directory of the package, which blurs the boundary Debian tries to
maintain between packaged and purely local software.

Even though the proposal is "optional", it still means that the packaged
luanti-server would change behaviour based on unmanaged filesystem
state. This makes it harder to reason about responsibility and support:
files under /usr/local are not tracked by dpkg, yet the package would
implicitly treat them as first-class mods.

Moreover, luanti already provides a policy-compliant mechanism to
achieve the desired flexibility. Mod and game paths can be overridden
via configuration in:

/etc/luanti/<game-instance>.env

This allows administrators to add arbitrary directories (including
/usr/local if they explicitly choose to do so) without hardcoding
/usr/local into the Debian package itself. In other words, the
separation between Debian-provided and locally provided content can
already be achieved in a configurable and explicit way, without
violating Debian’s conventions around /usr/local.

From a Debian packaging point of view, the following locations remain
appropriate:

* /usr/share/luanti/... for Debian-packaged games and mods,
* /var/lib/luanti/... for locally managed, persistent server data or
  extensions, 
* per-user directories (e.g. ~/.local/share/...) for user-installed
  mods.

Given this, I think it is better not to add /usr/local/share/luanti to
the default search paths in the Debian package. Administrators who want
to use /usr/local can already do so via configuration, while the package
itself stays within Debian Policy and preserves a clear separation of
responsibilities.

-- 
tobi

[toc] | [prev] | [next] | [standalone]

#1280402

On Sun, 01 Feb 2026 at 12:20:11 +0100, Tobias Frost wrote:
>According to the Filesystem Hierarchy Standard and Debian Policy,
>/usr/local is reserved exclusively for software and data installed by
>the local administrator and must remain outside the scope of Debian
>packages.

I'm with you so far.

>While Debian packages must not install files into /usr/local,
>they also should not define /usr/local as part of their intended runtime
>behaviour or interface.

I don't think that *necessarily* follows? /usr/local/bin is on the PATH by 
default, python3.13 looks for locally-installed Python code in 
/usr/local/lib/python3.13/dist-packages, every freedesktop.org 
specification that involves XDG_DATA_DIRS will look in locations like 
/usr/local/share/applications, and so on...

     smcv

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web