Server: landing page resource are not packaged correctly (tested in nightly debian packages)

[elpaso]

What is the bug or the crash?

Landing page resources are expected to be under

<prefix>/ogc/static/landingpage/

Where prefix is defined by server setting QGIS_SERVER_LANDING_PAGE_PROJECTS_DIRECTORIES which defaults to server setting QGIS_SERVER_API_RESOURCES_DIRECTORY which defaults to QgsApplication::pkgDataPath() ).absoluteFilePath( QStringLiteral( "resources/server/api" )

The last part of the path /ogc/static/landingpage/ is hardcoded.

After installing package qgis-server-landingpage 1:3.35.0+git20231126+ffb31addd7f+36jammy there is no /ogc/static/landingpage/ folder under /usr/share/qgis/resources/server/api/

Note that: to build the webapp along with QGIS server just turn the cmake flag WITH_SERVER_LANDINGPAGE_WEBAPP

Steps to reproduce the issue

install nightly server package

Versions

master

Supported QGIS version

• I'm running a supported QGIS version according to the roadmap.

New profile

• I tried with a new QGIS profile

Additional context

No response

[elpaso]

ping @jef-n

[jef-n]

Never used the landingpage. I see that liblandingpage.so and resources/server/src/landingpage/ is installed. But only the former is packaged. Is the .so usable w/o an app at all?

I guess the landingpage sources are installed to build a customized webapp after install on the target machine and WITH_SERVER_LANDINGPAGE_WEBAPP that would already build a default app at compile time.

Is the default app useful and should be packaged or does one need to configure and build the app after install anyway? The package qgis-server-landingpage should probably contain both and also depend on yarn(pkg) (which also depends on nodejs).

[elpaso]

Never used the landingpage. I see that liblandingpage.so and resources/server/src/landingpage/ is installed. But only the former is packaged. Is the .so usable w/o an app at all?

Short answer is no: without the JS/HTML part you only get the API but no web application, which defies the purpose of the landing page (AKA catalog): to be a ready to use QGIS webgis catalog.

I guess the landingpage sources are installed to build a customized webapp after install on the target machine and WITH_SERVER_LANDINGPAGE_WEBAPP that would already build a default app at compile time.

There is normally no need to build a custom app, it is possible to override the templates and the app by defining a custom folder for the HTML/JS assets with no need to rebuild anything from QGIS provided sources.

Is the default app useful and should be packaged or does one need to configure and build the app after install anyway?

The default app is 100% required and is the app that 99.99% of the users will use and need. It needs to be built and packaged.

The package qgis-server-landingpage should probably contain both and also depend on yarn(pkg) (which also depends on nodejs).

If it is not possible to ship pre-built JS files we need build them when the package is installed by providing yarn and all deps.

Note that it would be much better if we can ship pre-built JS assets.

[jef-n]

Why is this a regression? The packaging didn't change.

[jef-n]

There is normally no need to build a custom app, it is possible to override the templates and the app by defining a custom folder for the HTML/JS assets with no need to rebuild anything from QGIS provided sources.

Is the source, that is installed, needed to run the default app?

[elpaso]

Why is this a regression? The packaging didn't change.

I think it did at some point: originally the QGIS source tree contained the pre-built js code and the sources were hosted in a separate repo.

[elpaso]

There is normally no need to build a custom app, it is possible to override the templates and the app by defining a custom folder for the HTML/JS assets with no need to rebuild anything from QGIS provided sources.

Is the source, that is installed, needed to run the default app?

No.

[elpaso]

Why is this a regression? The packaging didn't change.

See history here: https://github.com/qgis/QGIS/commits/master/resources/server/api/ogc/static

At some point the pre-build JS and CSS were removed.

[jef-n]

Is the source, that is installed, needed to run the default app?

No.

Then why is it installed?

Correct me if I'm wrong: landingpage so and the default app should only be built and installed if WITH_SERVER_LANDINGPAGE_WEBAPP is enabled as the two require each other. And the source should not be installed, because it's not needed at runtime.

[elpaso]

Is the source, that is installed, needed to run the default app?

No.

Then why is it installed?

No idea, maybe it is required by some exotic debian policy? IIRC (but IANAL) the root of the problem was that pre-built js files were not allowed by debian (binary code is though) ?

The package as it is now makes no sense: the landing page does not work out of the box and there is no easy way to build a working package.

[jef-n]

No idea, maybe it is required by some exotic debian policy? IIRC (but IANAL) the root of the problem was that pre-built js files were not allowed by debian (binary code is though) ?

with "installed" I mean what the cmake install target does - not what gets installed when you install the package.

[elpaso]

Is the source, that is installed, needed to run the default app?

No.

Then why is it installed?

Correct me if I'm wrong: landingpage so and the default app should only be built and installed if WITH_SERVER_LANDINGPAGE_WEBAPP is enabled as the two require each other. And the source should not be installed, because it's not needed at runtime.

This is almost correct.

In theory, one could use the landing page JSON rest API without the client web app but I don't see any reason one should do it in practice.

[elpaso]

No idea, maybe it is required by some exotic debian policy? IIRC (but IANAL) the root of the problem was that pre-built js files were not allowed by debian (binary code is though) ?

with "installed" I mean what the cmake install target does - not what's get installed when you install the package.

I don't know: I didn't develop that part IIRC @pathmapper did.
My initial implementation was using pre-built JS/CSS assets directly, no build and no sources (which was a mistake and was corrected by integrating the sources in the QGIS source tree).

[pathmapper]

with "installed" I mean what the cmake install target does

This is the original PR with the whole story: #46643

As @elpaso already mentioned, before there were pre-built JS assets in the QGIS source tree.

Now, there are only the sources included and if the flag WITH_SERVER_LANDINGPAGE_WEBAPP is enabled (and Node.js and Yarn are available at build time), the server landigpage/catalog webapp is built when building QGIS and is ready to use with QGIS Server.

https://docs.qgis.org/3.28/en/docs/server_manual/catalog.html

I noticed as well that the Debian/Ubuntu packages are not including the webapp anymore (they did when pre-built JS assets were included in the source tree - hence a regression).

So if one want to use the landingpage/catalog webapp currently with QGIS server there is a need to build it manually (with QGIS sources) and copy it to the specific folders to make it available for QGIS Server.

This is not ideal and it would be great if Debian/Ubuntu (and other) packages would include the webapp which is usable out of the box.

[elpaso]

@jef-n do you see any possibility to fix this? I will remove the landing functionality altogether if we don't find a solution: it doesn't make sense to ship it without the JS and HTML/CSS code.

[jef-n]

@jef-n do you see any possibility to fix this? I will remove the landing functionality altogether if we don't find a solution: it doesn't make sense to ship it without the JS and HTML/CSS code.

Sure - not sure when though.

[elpaso]

@jef-n any chance to get this fixed during this bug-fixing round?

[elpaso]

@jef-n gentle ping ...