get last update timestamp from XX-index.timestamp's modification time

[tvestelind]

The reason we cannot the timestamp of the last update it from
XX-index.tar is because it's modification time is not updated unless
there is a newer version available in the repository.

On the other hand, XX-index.timestamp's modification time is always
updated, even if there are no new updates. That means that the
modifiation time of file will correspond to the last update attemp. So,
to decide whether to warn about having an old index we can use the last
modification time of that file.

One could also have the modification time of XX-index.tar updated even
thought there aren't any updates, but to do that I think we'd need to
modify checkForUpdates in Hackage.Security.Client.

Signed-off-by: Tomas Vestelind [email protected]

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.

This fixes #4444 and I tested this by following the steps to reproduce described in that issue. But to summarize, I did:

1. Add next-hackage to my .cabal/config
2. Built the latest cabal-install from master
3. Ran ./dist/build/cabal/cabal update (I'll exclude the ./dist/.../ part from now one, it's just to show that I really used what I build)
4. Went to cabal/packages/next-hackage and used touch to set the modification date on all files to one year ago
5. Ran cabal install and verified that I got the error Warning: The package list for 'next-hackage' is 365 days old.
6. Ran cabal update && cabal install and verified that the error was still there.
7. Implemented my suggested solution
8. Ran cabal update && cabal install and verified that the error was gone.

[mention-bot]

@tvestelind, thanks for your PR! By analyzing the history of the files in this pull request, we identified @hvr, @dcoutts and @owst to be potential reviewers.

[23Skidoo]

This is nice, but doesn't this only work for for secure repos? In the non-secure case we don't have the .timestamp file:

$ ls ~/.cabal/packages/hackage.scrive.com/ 
00-index.cache        consumers/    happstack-static-routing/
00-index.tar          curl/         kontrakcja-templates/
00-index.tar.gz       dataenc/      mixpanel/
00-index.tar.gz.etag  fields-json/  resource-pool/

[hvr]

I just want to point out that --index-state makes only sense for secure type repos and (possibly - I don't rememeber OTTOMH if the current logic allows to use --index-state with 00-index) for non-secure repos which avoid .cabal revisions. Using --index-state with a non-secure repo + revisions will result in unsound states.

[tvestelind]

Sorry, I thought that we wrote a .timestamp file in all cases. I'll have to rethink the solution then.

Do you think that I should look into updating the modification time for XX-index.tar?

[23Skidoo]

Re: --index-state, it's not enabled by default, while this PR changes the default behaviour. So I'm okay with --index-state being secure-only. Though we should fail with an error (if possible) instead of going into an unsound state.

@tvestelind

Do you think that I should look into updating the modification time for XX-index.tar?

I think that'd be a valid solution.

[23Skidoo]

Closing in favour of #4950.