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++
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.
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.
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.
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:
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
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.
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
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] [source]
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:
drh edit: activate link