Packaging
(1.1) By sodface on 2022-01-15 21:44:26 edited from 1.0 [link] [source]
I see the Makefile defines both althttpd and althttpsd. What would be desired as far as downstream binary package distribution?
althttpd would only support http and althttpsd would support http/https so distributing both in the same package wouldn't seem like the right answer.
It seems like the options are:
Two different packages. Though the project itself is called althttpd which now implies the http only version and complicates a package search.
One package with both althttpd and althttpsd which seems silly as althttpsd provides all the functionality of althttpd anyway, and would pull in the required dependencies whether you wanted them or not.
One package with just althttpsd, but what to name the package?
One package called althttpd, with a binary name of althttpd that was compiled with TLS support. You get the extra dependencies whether you want them or not.
The last option is what I did for my local package testing before I read the Makefile.
(2) By drh on 2022-01-15 22:26:17 in reply to 1.1 [link] [source]
I was thinking that we'd eventually go with a single "althttpd" that includes TLS, because the current "althttpsd" binary works both ways. But I'm open to alternative suggestions.
(3) By Stephan Beal (stephan) on 2022-01-16 01:04:38 in reply to 2 [link] [source]
I was thinking that we'd eventually go with a single "althttpd" that includes TLS, because the current "althttpsd" binary works both ways.
FWIW, that was my eventual intent, but added both binaries to the build to ensure that the canonical build still works without having to reconfigure and rebuild. Once we're happy with TLS then that extra target is absolutely superfluous.
(4) By sodface on 2022-02-18 12:16:34 in reply to 1.1 [link] [source]
Another packaging related question:
I see references to a version number of "2.0" which sort of implies that there has been a numbered release which I don't think is the case? For the Alpine package version, I'm using a timeline date format which pulls the source for that commit, currently 202108141729.
I haven't submitted an update yet. Do you have a preference on how the package should be versioned?
(5) By Stephan Beal (stephan) on 2022-02-18 14:21:20 in reply to 4 [source]
I see references to a version number of "2.0" which sort of implies that there has been a numbered release which I don't think is the case?
Correct. althttpd has been in production use practically since the cavepeople walked the earth, but never had (nor needed) a version number. The hacking in and around integrating TLS included adding build info into the binary so that it's easy to see whether a given binary has TLS support. Since we were already adding that, it made sense to add a version string at the same time and Richard decided has finally reached 2.0.
Do you have a preference on how the package should be versioned?
Can't answer that one - that's up to Richard.
(6.3) By sodface on 2022-03-20 18:53:16 edited from 6.2 in reply to 1.1 [link] [source]
Just an update on this: I had not submitted an update to the Alpine package since the addition of the integrated TLS support and decided yesterday that I probably should get it updated. Working with one of the Alpine devs, we ended up:
- Keeping a single package with no name change, still named althttpd
- Keeping a single binary, still called althttpd but built with TLS support
- Keeping the package version format based on the check in, eg. 202203201558
- Adding a -doc subpackage for althttpd.md
Yesterday's MR is here for 202203180956 which is what's in the edge repo as I type this. Unfortunately, I did not catch the standalone 10s timeout until after it was pushed (some thorough testing I did).
Today's MR for 202203201558 which includes the standalone timeout fix is submitted and passed CI so hopefully it gets merged today and the repo will be updated shortly thereafter.