Webapp is incompatible with FHS compliant build

[GugolPlex]

Description of the problem

The new webapp/public/index.php in 8.3.0dev is not compatible with configure --enable-fhs. It seems impossible to build a working FHS-compliant domserver.

Your environment

• DOMjudge 8.3.0dev (snapshot domjudge-snapshot-20240303.tar.gz)
• Debian 12.5

Steps to reproduce

After install all prerequisites and untar the source code from the last 8.3.0dev snapshot:

./configure --enable-fhs  --disable-doc-build --disable-judgehost-build
[...]

Summary:
 * project.............: DOMjudge 8.3.0DEV
 * prefix..............: /usr/local
[...]
 * domserver...........: 
    - bin..............: /usr/local/bin
    - etc..............: /usr/local/etc/domjudge
    - lib..............: /usr/local/lib/domjudge
    - libvendor........: /usr/local/lib/domjudge/vendor
    - log..............: /usr/local/var/log/domjudge
    - run..............: /usr/local/var/run/domjudge
    - sql..............: /usr/local/share/domjudge/sql
    - tmp..............: /tmp
    - webapp...........: /usr/local/share/domjudge/webapp
    - example_problems.: /usr/local/share/domjudge/example_problems
    - database_dumps...: /usr/local/var/lib/domjudge/db-dumps

 * systemd unit files..: /lib/systemd/system

Note that the main webapp will be located at /usr/local/share/domjudge/webapp and PHP vendor libs at /usr/local/lib/domjudge/vendor.

Unfortunately, ./webapp/public/index.php was changed and now is content is:

<?php declare(strict_types=1);

use App\Kernel;

require_once dirname(__DIR__, 2) . '/lib/vendor/autoload_runtime.php';
[ ... ]

When installed, that require_once looks for the file /usr/local/share/domjudge/lib/vendor/autoload_runtime.php but that file is missing because it is stored in the libvendordirectory, far from the webapp directory when FHS is enabled. The correct path should be /usr/local/lib/domjudge/vendor/autoload_runtime.php. In fact, that file exists after make install.

configure provides two parameters to change the lib and libvendor directories so this could be a workaround:

./configure --enable-fhs  --disable-doc-build --disable-judgehost-build \
            --with-domserver_libdir=/usr/local/share/domjudge/lib/ \
            --with-domserver_libvendordir=/usr/local/share/domjudge/lib/vendor
[...]

Summary:
 * project.............: DOMjudge 8.3.0DEV
 * prefix..............: /usr/local
[...]
 * domserver...........: 
    - bin..............: /usr/local/bin
    - etc..............: /usr/local/etc/domjudge
    - lib..............: /usr/local/share/domjudge/lib/
    - libvendor........: /usr/local/share/domjudge/lib/vendor
    - log..............: /usr/local/var/log/domjudge
    - run..............: /usr/local/var/run/domjudge
    - sql..............: /usr/local/share/domjudge/sql
    - tmp..............: /tmp
    - webapp...........: /usr/local/share/domjudge/webapp
    - example_problems.: /usr/local/share/domjudge/example_problems
    - database_dumps...: /usr/local/var/lib/domjudge/db-dumps

 * systemd unit files..: /lib/systemd/system

Now libvendor it is located in a path compatible with the new index.php. But these options seems to be ignored by make install-domserver because nothing changes in the installation paths. autoload_runtime.php ends in the same /usr/local/lib/domjudge/vendor folder and the webapp doesn't work.

[vmcj]

@GugolPlex do you have a specific reason why you encountered this issue? We're considering (and on the way of implementing) not giving this option anymore and have the libvendor files always under the webapp. Given that you encountered this issue I think it's fair to notify you as this might break your build.

[GugolPlex]

Hello,

What option do you mean? I tried using --with-domserver_libdir and --with-domserver_libvendordir in order to solve the issue with the FHS, but I do not usually use them.

But I've been using --enable-fhs for more than 10 years (DOMjudge 3.x). As far I know, /usr/local is the place where inhouse compiled software should be stored. /opt is for prepackaged external binary applications. So, the natural place where configure and make should generate their artifacts (for local use) is /usr/local, not /opt This is the reason because I always use --enable-fhs that now is broken in 8.3DEV.

If --enable-fhs is the option that will be removed, then, in my opinion, DOMjudge is assuming that people will use it only through pre-build packages because it is not possible to have a running version using the /usr/lcoal paths, the expected route for inhouse builds.

Thx.

[eldering]

Hi @GugolPlex. To clarify: we're looking with #2428 into simplifying things by removing the option to set the path to lib/vendor separately from the webapp directory. That will also fix the issue you're encountering long-term.

So we're not planning to remove the --enable-fhs option, although we were wondering if it was used (much). So I think we can take your answer as a clear sign of usage.