Use timestamps for detecting "new" packages and updating the database.

[ruro]

It is common for UNIX applications to rely on file timestamps for determining, which files are "new" and which are "old". For example make, git and rsync. I think, repose should also use this mechanism more actively.

In particular, I have 2 suggestions:

1. Currently, if the .db and .files are already up to date, repose just prints a message and exits. I think, in this case, the files should also be touched (their timestamp should be updated). That way, you can use make to build the .db file. In the current situation, if make thinks, that the .db file is "old" and repose thinks, that it is up to date, its timestamp will never be updated and so make will still think, that the database is outdated even after "building" it.

2. This might be a bug, or my misunderstanding of how repose determines, which packages are "new" (step 2 in README "If we find a new package in the database's folder, add it to the database.").
   
   Currently, if I build a packagename.pkg.xz via makepkg, then run repose and then build it again, increasing the pkgver or pkgrel, then makepkg will report, that the database is up-to-date, even though the packagename.pkg.xz file contains a newer version of the package.
   
   Maybe, I am misunderstanding the "intended" way to use repose. If my use case is valid, I would suggest also considering a .pkg.xz as "new" if it has a timestamp, that is newer than the timestamp of the .db file.

[Seoka]

Hmm,
On the first hand you are right, as this checks for updates, but I think inotify is better suited for keeping the database up to date. It would then get a kind of service through...

[ruro]

Inotify is only useful, if you want to monitor the status of files as they change. I don't think, that this is a common use case for repose. If my understanding is correct, most people use repose as a "package database compiler". This means that repose is only being run manually after a package is added or updated by the user.