New package: element-web-1.11.13

[TinfoilSubmarine]

Move element-desktop, riot-desktop to subpackage of element-web

Testing the changes

• I tested the changes in this PR: YES

New package

• This new package conforms to the package requirements: YES

I've had element-desktop installed on my server and just pointing reverse proxy at /usr/lib/element-desktop/resources/webapp, but I also had to ignorepkg all of the dependencies. This fixes that :)

I didn't bump the revision since there aren't any functional changes to element-desktop, but I can if needed.

[TinfoilSubmarine]

That's a shame that electron19 makes this so restrictive. Guess for now I'll just make element-web its own package.

[paper42]

I am not sure webapps are a good fit for void-packages. I am not saying no to this package, I just want to document my thoughts and I might be wrong about some things. Feel free to correct me.

Working with groups for web apps is a mess with Void because we don't have a standardized group for all of them. apache uses a different default group than nginx, etc. Also because of how void packages work, group IDs are not known before the group is added, so fixing this would not only break backwards compatibility, but it would also have to add a group to base-files (where we can control GID). It's possible element-web doesn't need write access to these files, in that case this point is not relevant. I got stuck at this point with my nextcloud server package.

I am not sure what value is there in rebuilding everything with yarn. All webapps I worked with provide a nice pre-built tarball and then there isn't a big point in repackaging their archive when you could just unpack it. We would just be removing the webapp from its box and adding it to our own box.

I don't know if it's in the scope of void-packages to package webapps. There is a ton of them, they are often quite big (nextcloud is 350MB). They are probably very low effort for both packaging and manually installing them, but someone needs to keep them up to date, fix their CVEs and CVEs of their dependencies which is often a lot of 3rd party packages.

(this doesn't apply here, but I will mention it anyway) If you have a webapp that uses php8.0 and we decide to change its dependency to php8.1 (which you have installed, but not enabled), you will not notice this in the update because there won't be any new packages installed, just the webapp will get an update until you run xbps-remove -o. This is because xbps by design doesn't handle enabling and disabling services and this is not something we can fix. We could only document it with an install message...

I also see some benefits in packaging webapps - simple updates with the rest of your system, proper system dependency tracking, etc. I personally use docker-compose, so I don't have to care about any of these issues.

[TinfoilSubmarine]

These are all good points, and several are ones I've run into before that have stopped me from packaging something, or at least from submitting a template I've been using for my own machines.

I will say that I would consider this PR to be an exception to that reasoning since we have several different matrix servers packaged and it would be nice for convenience sake to be able to install a client as well.