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