Hello again. > To me, this feels more like a demo of how to use the code than > something that most people would run themselves. If that's the case, > then packaging it is probably overkill (and maybe even a bad idea, if > it hasn't been coded defensively enough to run as an internet-facing > service).
Sort of like that. It's a playground like the title suggests. So I guess your vote is option number 2 (total removal, not merging and not separating it in a subpackage). I'll start working on it like that unless I hear any objections. > Also, as-is the rc script runs it as root, which is not good. But > until we either have dynamic uid allocation or figure out some uid > range that we can extend into for ports that doesn't cause big > problems for too many people, individual uids for ports are a scarce > commodity. I think this is probably not useful enough to use one up > on. Don't scare me like that. It's actually running as www. I've just rechecked with top: 6751 www 2 0 85M 13M sleep/1 kqread 0:00 0.00% gochromad On Wed, 2026-07-08 at 17:18 +0100, Stuart Henderson wrote: > On 2026/07/08 18:11, Igor Zornik wrote: > > Hello, > > > > > I don't see a reason to split them out to a subpackage; include > > > the > > > files in the main package if they're useful, or drop them if not. > > > > Indeed, but apparently that's a bit subjective so who exactly > > decides what is useful? Maintainer or reviewers/approvers? For > > additional context, what "-web" does is it basically runs this > > website > > https://swapoff.org/chroma/playground/ on your local machine. > > > > When I make a port, I try to be fair towards both project developers > > and ports consumers, so I try to include the project in its > > entirety. > > It is through a discussion on the ports mailing list with > > knowledgable > > and authoritative people that we conclude if or what is appropriate > > to > > commit into the ports tree and what to omit. > > Yes. > > To me, this feels more like a demo of how to use the code than > something > that most people would run themselves. If that's the case, then > packaging > it is probably overkill (and maybe even a bad idea, if it hasn't been > coded defensively enough to run as an internet-facing service). > > Also, as-is the rc script runs it as root, which is not good. But > until > we either have dynamic uid allocation or figure out some uid range > that > we can extend into for ports that doesn't cause big problems for too > many people, individual uids for ports are a scarce commodity. I think > this is probably not useful enough to use one up on.. > > > Currently I see three options for -web. I'm fine with any, but > > obviously > > hold a preference for the 1st one. I justified my reasons in OP: > > > > - Keep as is, possibly amending DESCR. > > - Remove. > > - Merge into main, that is remove subpackaging. > > > > Thanks for additional tips and instructions. I understood them all > > and > > will incorporate them into my next revision as soon as we decide the > > fate of this subpackage. > > > > On Wed, 2026-07-08 at 11:31 +0100, Stuart Henderson wrote: > > > On 2026/07/07 21:28, Igor Zornik wrote: > > > > Hi! > > > > > > > > Thanks for looking into it. As for the comments: > > > > > > > > > Any reason to name the port go-chroma instead of just chroma? > > > > > > > > There's already a chroma port. It's mentioned in the Makefile. > > > > I'm > > > > open > > > > for accepting a better solution to resolve naming conflicts. > > > > > > It's called "chroma-syntax-highlighter" on repology and freebsd. A > > > bit > > > of a mouthful, but I think it's helpful to use an existing name if > > > there is one. > > > > > > If including chromad, I'd only rename the "chroma" binary and > > > leave > > > "chromad" as-is, as there's no conflict for that one. Or skip > > > renaming > > > and just let them conflict.. > > > > > > I'd rename the binary to something that works with "chroma<tab>" > > > if > > > renaming (chroma-hl?). > > > > > > > > Is the -web subpackage really useful? > > > > > > > > Well, no. As I've already written in my opening post, it seems > > > > it > > > > serves > > > > mostly for demonstrative purposes and it looks nice so I've > > > > added it > > > > anyway as an option. That's my personal take on it. I can modify > > > > DESCR > > > > based on further decisions. > > > > > > I don't see a reason to split them out to a subpackage; include > > > the > > > files in the main package if they're useful, or drop them if not. > > > > > > > > Anyway is there an issue with tgz? It doesn't seem to build > > > > > here: > > > > > > > > Sorry to hear that. I don't know what could've gone wrong. It > > > > looks > > > > OK > > > > to me. I've prepared another .tgz with the port updated to 2.27 > > > > as > > > > that > > > > was released in the meantime. 'make install-all' works on > > > > today's > > > > amd64 > > > > snap. I've also replaced tab with a space in WANTLIB. Hopefully > > > > you'll > > > > have better experience with this version. > > > > > > builds ok here. (I didn't try the older one). does also need > > > NO_TEST=Yes. > > > > > > > >
