Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#75214 - Allow package install date to be overriden

Attached to Project: Pacman
Opened by Henry (xjzi) - Saturday, 02 July 2022, 15:12 GMT
Task Type Feature Request
Category General
Status Unconfirmed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 6.0.1
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Summary and Info:
In lib/libalpm/add.c:594, the the new package's install date is set with time().
This makes it hard to use pacman to build something that should be fully reproducible.
There are two workarounds:
- I can use libfaketime to control the install date: https://github.com/wolfcw/libfaketime.
- I can modify package desc files to have a different time.
However, the best solution would be to have pacman respect the SOURCE_DATE_EPOCH environment variable.

reproducible-builds.org explains this well.
Timestamps: https://reproducible-builds.org/docs/timestamps/
SOURCE_DATE_EPOCH: https://reproducible-builds.org/specs/source-date-epoch/

Steps to Reproduce:
Install a package with pacman.
/var/lib/pacman/local/PKG_NAME/desc will contain the time the package was installed under %INSTALLDATE%.
This task depends upon

Comment by Doug Newgard (Scimmia) - Saturday, 02 July 2022, 15:24 GMT
How does the installation time have anything to do with *package* reproducibility? It's not part of the package at all.
Comment by Henry (xjzi) - Saturday, 02 July 2022, 15:43 GMT
The build product is not a package, but a root Arch Linux filesystem.
Comment by Doug Newgard (Scimmia) - Saturday, 02 July 2022, 15:51 GMT
Then your links to reproducible-builds.org is misleading.

"Reproducible builds are a set of software development practices that create an independently-verifiable path from source to binary code."
Comment by Henry (xjzi) - Saturday, 02 July 2022, 16:28 GMT
Comment by Henry (xjzi) - Saturday, 02 July 2022, 16:28 GMT
Comment by Henry (xjzi) - Saturday, 02 July 2022, 16:32 GMT
I didn't mean to send it that many times, must have been caused by reloading the page. Anyways, as far as reproducibility is concerned, the difference between an executable and a filesystem is purely semantic. They are both distributed to many people who should be able to confirm they have a legitimate copy. Take arch installation isos.
Comment by Allan McRae (Allan) - Sunday, 03 July 2022, 00:43 GMT
When building an install/iso, there are a lot of other timestamps to worry about. So libfaketime would be the solution. However, I believe archboot does a sed over the install times.
Comment by Henry (xjzi) - Sunday, 03 July 2022, 01:48 GMT
The only other timestamp issue I've come across was caused by mkfs.erofs, which supports a command line argument to specify the time and it respects SOURCE_DATE_EPOCH. Now these desc files are the only difference between consecutive builds. Also, libfaketime would be slightly inconvenient because pacman is running in a chroot, so I would have to drop in the so file and take it out afterwards. I am running pacman from pacstrap from archiso from my script, so there is not a lot of room for command-specific customization unless I deviate from the mainstream archiso script, which I'm tempted to do. I will probably just use sed like you suggested.

Although I am curious why you don't think respecting an environment variable is the "correct" solution. libfaketime needs extra configuration for java, and doesn't work in languages like go. The pacman code may remain untouched if you relegate the problem to libfaketime, but everyone using pacman in a reproducible context has to make their own code uglier to deal with the exception.

Loading...