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