Commit 36746d1
committed
fix apt cache timestamp logic
I just stumbled upon a host where there is not `update-success-stamp`
at all. Turns out this file is actually site-specific to our
environment and is created by a Puppet module we use.
It's not standard: the APT::Periodic feature flags updates with the
`update-stamp` file instead!
So let's split the check into multiple, distinct heuristics:
1. if the `update-success-stamp` file exist, use it and disregard the
rest
2. failing that, if `APT::Periodic` is configured, check
`update-stamp`, which does roughly the same (but won't update on a
plain `apt update`)
3. failing that, check `/var/lib/apt/lists/partial` which *works* but
might give a false timestamps when apt-get *fails* to get an
update, as that directory's timestamp is always updated
Because of (3), we still need the other heuristics.
Signed-off-by: Antoine Beaupré <anarcat@debian.org>1 parent 76a6617 commit 36746d1
1 file changed
Lines changed: 13 additions & 6 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
94 | 94 | | |
95 | 95 | | |
96 | 96 | | |
97 | | - | |
98 | | - | |
99 | | - | |
100 | | - | |
101 | | - | |
102 | | - | |
| 97 | + | |
| 98 | + | |
| 99 | + | |
| 100 | + | |
| 101 | + | |
| 102 | + | |
| 103 | + | |
| 104 | + | |
| 105 | + | |
103 | 106 | | |
| 107 | + | |
| 108 | + | |
| 109 | + | |
| 110 | + | |
104 | 111 | | |
105 | 112 | | |
106 | 113 | | |
| |||
0 commit comments