Re: New package: element-web-1.11.8

[paper42 <paper42@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 2307 bytes --]

New comment by paper42 on void-packages repository

https://github.com/void-linux/void-packages/pull/39554#issuecomment-1264132535

Comment:
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.