| 1 |
Il 17/03/2018 00:40, Kent Fredric ha scritto: |
| 2 |
> On Mon, 12 Mar 2018 07:55:46 +0900 |
| 3 |
> Benda Xu <heroxbd@g.o> wrote: |
| 4 |
> |
| 5 |
>> Ha, indeed many packages hardwrites "date of build" alike. That is a |
| 6 |
>> hard question to define reproducibility. I would rather ignore the |
| 7 |
>> timestamps when comparing two binaries. |
| 8 |
> If a hard-timestamp is to be used, assuming you have portage via git, |
| 9 |
> then it might be desirable to hard-timestamp based on either: |
| 10 |
> |
| 11 |
> a) the timestamp of the specific ebuilds last change |
| 12 |
> b) the timestamp of the most-recent-of specific ebuild+eclass's last change |
| 13 |
> c) the timestamp of the specific ebuilds initial commit |
| 14 |
d) for rsync users the timestamp of the repository, kept in metadata/, |
| 15 |
the timestamp of last commit otherwise |
| 16 |
> |
| 17 |
> I'm not sure which one is more practical though. |
| 18 |
> |
| 19 |
> Sounds like it would be an "experts" tool which would become far more practical |
| 20 |
> for people who are using custom overlays to maintain their production systems, |
| 21 |
> and those people can naturally make guarantees about their repos being in git, |
| 22 |
> and they can decide which of those 3 options ( well, the ones we |
| 23 |
> provide at least ) are most suited to what they're doing. |
| 24 |
> |
Archives