https://sqlite.org/docsrc/zip?ci=ad2370ccce&in=misc/althttpd.c

That creates a ZIP archive for a particular check-in of althttpd.c. Maybe that's what you want. But would you rather have a generic link? If you replace "ad2370ccce" with "trunk", you'll get the latest trunk check-in. If you replace "ad2370ccce" with "release" you'll get the latest official release version.

Also, the download filename is just "zip". You can add a better name before the ? in the URL. For example:

https://sqlite.org/docsrc/zip/althttpd-20200509.zip?ci=...

The part that comes after "/zip/" and before "?" can be anything you want. Whatever it is becomes the name of the download file.

I thought about using the trunk link so I didn't have to update it but the abuild package system appends source file checksums in the package build file so a specific package version would fail to (re)build if there was a new check-in.

For my own use this might even be a good thing but I think official packages have to be repeatable.

The packaging system provides a facility for renaming the downloaded source file which I was using but thanks for the tip on specifying a name, I will switch to that.

It occurs to me I might need to re-think the date style version number, not sure how the package manager determines how one package is newer than another. Would it consider 04.01.2019 to be newer than 01.04.2020 for example? I might need to put the year first.

I might need to put the year first.

Yes. Please, always use a format of YYYYMMDD or YYYY-MM-DD. Big-endian dates only. See ISO-8601.

https://sqlite.org/docsrc/zip?ci=ad2370ccce&in=misc/althttpd.c

If you use the YYYY-MM-DD date format for pkgver, I think that you can use it as the ?ci=... argument in the URL, too. (The actual format supported by Fossil in some places where checkin hash is expected is YYYY-MM-DDTHH:MM:SS.SSS, but the date can be truncated.)

More recent versions of Fossil let you omit the punctuation and use tags like "YYYYMMDDHHMM" or "YYYYMMDDHHMMSS". So, the link could be just:

• https://sqlite.org/docsrc/zip/althttpd.zip?ci=202005092232&in=misc/althttpd.c

Specifying the filename as part of the url doesn't appear to work with Alpine's build tools. Using a url like:

https://sqlite.org/docsrc/zip/althttpd.zip?ci=202005092232&in=misc/althttpd.c

the abuild tool fetches the file and the local filename is althttpd.c instead of althttpd.zip, though the .c file is actually zipped. I'll probably go back to using the Alpine syntax for renaming in the form:

althttpd.zip::https://sqlite.org/docsrc/zip?ci=202005092232&in=misc/althttpd.c

The first form is named correctly when downloading with firefox but abuild is probably using wget or something on the backend and it's not producing the intended filename.

Confusingly, when downloading with firefox:

https://sqlite.org/docsrc/zip/althttpd-1.zip?ci=202005092232&in=misc/althttpd.c
https://sqlite.org/docsrc/zip/althttpd-2.zip?ci=202004281307&in=misc/althttpd.c
https://sqlite.org/docsrc/zip/althttpd-3.zip?ci=202003251125&in=misc/althttpd.c

md5sums are all different as expected.

$ md5sum althttpd-*
fcdd2ddd3f6e546f5dea665e51dbc12f  althttpd-1.zip
993e1b78581a7d9a1f17dcbe21cd25c0  althttpd-2.zip
bb7d72e9a01a3745163f416823f42d2a  althttpd-3.zip

But if I use the same filename and let firefox rename, the md5sums are the same:

https://sqlite.org/docsrc/zip/althttpd.zip?ci=202005092232&in=misc/althttpd.c
https://sqlite.org/docsrc/zip/althttpd.zip?ci=202004281307&in=misc/althttpd.c
https://sqlite.org/docsrc/zip/althttpd.zip?ci=202003251125&in=misc/althttpd.c

$ md5sum althttpd*
6a09f995294fc12587a94ee38a483f92  althttpd(1).zip
6a09f995294fc12587a94ee38a483f92  althttpd(2).zip
6a09f995294fc12587a94ee38a483f92  althttpd.zip

Sorry for the multiple posts. I edited the APKBUILD to set pkgver to the full date tag "YYYYMMDDHHMM" and used ci=$pkgver in the source url. I'm setting the download source filename to $pkgname-$pkgver.zip I ran abuild checksum twice with two different date tags in pkgver and abuild computed the same checksum

sha512sums="-snip-06a13d  althttpd-202005092232.zip

sha512sums="-snip-06a13d  althttpd-202004281307.zip

I'm probably doing something obviously wrong here but I'm not seeing it.

When specifying a filename, the filename without the .zip suffix is contained in the resulting zip file. The md5sums for the first three above are different because of the difference in the folder names contained in the zips. The actual althttpd.c source code files are identical however.

This also explains why the last three with the same name have matching checksums.

I believe the problem with all the examples on this page, including the one in my first post, is that we should be using r= instead of ci=

With ci= I think it is ignored and you just always get the latest trunk check-in.

Testing with r= gives me the expected results.

Sorry for causing confusion.

Just wanted to follow up on this. I packaged this for my own use originally but also just got it merged into Alpine's testing repo:

https://pkgs.alpinelinux.org/packages?name=althttpd&branch=edge

drh edit: activate link