You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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...
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.
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
andrsync
. I think,repose
should also use this mechanism more actively.In particular, I have 2 suggestions:
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 betouch
ed (their timestamp should be updated). That way, you can use make to build the.db
file. In the current situation, ifmake
thinks, that the.db
file is "old" andrepose
thinks, that it is up to date, its timestamp will never be updated and somake
will still think, that the database is outdated even after "building" it.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
viamakepkg
, then runrepose
and then build it again, increasing thepkgver
orpkgrel
, thenmakepkg
will report, that the database is up-to-date, even though thepackagename.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.The text was updated successfully, but these errors were encountered: