From: paper42 <firstname.lastname@example.org>
Subject: Re: New package: element-web-1.11.8
Date: Sat, 01 Oct 2022 01:43:54 +0200 [thread overview]
Message-ID: <20220930234354.Ew9_suItwLo1KIP0FUGVQi1uBB9putmQ2Qwc9EELpkU@z> (raw)
[-- Attachment #1: Type: text/plain, Size: 2307 bytes --]
New comment by paper42 on void-packages repository
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.
next prev parent reply other threads:[~2022-09-30 23:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-30 21:17 [PR PATCH] New package: element-web-1.11.8 (and move element/riot-desktop as subpackages) TinfoilSubmarine
2022-09-30 23:02 ` TinfoilSubmarine
2022-09-30 23:05 ` [PR PATCH] [Updated] " TinfoilSubmarine
2022-09-30 23:43 ` paper42 [this message]
2022-10-03 1:31 ` [PR PATCH] [Updated] New package: element-web-1.11.8 TinfoilSubmarine
2022-10-03 1:33 ` TinfoilSubmarine
2022-10-14 13:00 ` [PR PATCH] [Updated] " TinfoilSubmarine
2022-10-27 12:31 ` [PR PATCH] [Updated] New package: element-web-1.11.10 TinfoilSubmarine
2022-11-01 13:28 ` [PR PATCH] [Updated] New package: element-web-1.11.12 TinfoilSubmarine
2023-01-20 15:01 ` [PR PATCH] [Closed]: New package: element-web-1.11.13 TinfoilSubmarine
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).