martinetd
commented
1 year ago By the way for the same reason I was playing with setting a --cache-dir in APK_OPTS (with a suitable cache-max-age; yes, I know, it's bad to install older software as security issues etc, it's mostly for CI and hopefully won't be used with really old caches)
At that point I ran into the issue that the main install command in the script has --update-cache . . . Is there any reason for that option? The default 4h cache is probably fine for everyone.
If you don't see a problem with that I'll send a PR to remove that option, and that at least solves the timestamp problem for me: I can just use the cache creation date.
Hello,
in order to generate delta updates I've been looking at making the archive generated by alpine-make-rootfs reproducible today.
In my experience there are two places that weren't reproducible:
/lib/apk/db/scripts.tarwhen installing packages. apk respectsSOURCE_DATE_EPOCHso setting that appropriately works and is enough. (more on the variable later)--sort=name --mtime=@$SOURCE_DATE_EPOCH --clamp-mtime --pax-option=exthdr.name=%d/PaxHeaders/%f,delete=atime,delete=ctimeto the tar creation line.Now the big question is what would SOURCE_DATE_EPOCH should be. The simplest approach is to say, if it's set from outside of alpine-make-rootfs we should just use it (that is true even if we add some detection later), so we probably should add the tar creation option conditionally on that.
As for setting it automatically, I think we could fetch the APKINDEX of the repos we're installing from and taking the latest timestamp in there... It's a bit annoying because we need to set it before running apk, and apk is the one getting the APKINDEX, so it's a bit of a chicken and egg problem... I need to check if we can just regenerate scripts.db later maybe...
What do you think?