SQLite Forum

Packaging althttpd

Packaging althttpd

(1) By sodface on 2020-05-17 13:50:58 [link]

I'm packaging althttpd for Alpine Linux and hosting the package file in a personal repo (said repo is being served by althttpd also).

I'm using a date format in the package build as a version number:


A link to the src:


and this link for the overall project url:


Just wondering if this looks about right?  The package builds fine and creates an open-rc sub-package to integrate with the service management system.

It took me a few tries to come up with the src url but I believe the form above will always get the same source that corresponds with the version date as listed in the pkgver variable?  To update the build I'm changing the version date and the ci= portion of the src url to the new check-in string.

I'm also applying a patch to allow plus signs in filenames as many of the files in the repo have them, eg. c++

(2) By Richard Hipp (drh) on 2020-05-17 14:00:50 in reply to 1 [link]

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


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

(3) By sodface on 2020-05-17 14:18:41 in reply to 2 [link]

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.

(4) By Richard Hipp (drh) on 2020-05-17 14:49:33 in reply to 3 [link]

>  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][1].

[1]: https://en.wikipedia.org/wiki/ISO_8601

(7) By sodface on 2020-05-17 18:46:47 in reply to 2

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


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:


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.

(5) By anonymous on 2020-05-17 15:26:35 in reply to 1 [link]

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

(6) By Richard Hipp (drh) on 2020-05-17 16:22:09 in reply to 5 [link]

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>

(8) By sodface on 2020-05-17 19:22:50 in reply to 6 [link]

Confusingly, when downloading with firefox:


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:

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

(10) By sodface on 2020-05-19 02:34:42 in reply to 8 [link]

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.

(9) By sodface on 2020-05-17 19:43:56 in reply to 6 [link]

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.

(11.1) Originally by sodface with edits by Richard Hipp (drh) on 2020-09-06 17:48:51 from 11.0 in reply to 1 [link]

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:


<font color="gray">*drh edit: activate link*</font>