On 2/6/21 12:28 am, Christian Hesse wrote:
Christian Hesse <list@eworm.de> on Fri, 2021/05/28 17:55:
Allan McRae <allan@archlinux.org> on Fri, 2021/05/28 22:52:
Does this mean the "new" database on the hosts network could be long out of date, but as long as it is newer than the local machine being updated, that is what will be used?
Well, out-of-date is a term that does barely match here... pacman does known about the date of its current database files only. So yes, more recent database files are used as long as they are newer than the local ones - even if out-of-date compared with a mirror.
That's why the pacredir documentation tells you to run `pacman -Sy` twice to be sure: First run fetches the newest database from local network, second run (where pacredir returns 404) fetches from mirror if a newer version is available.
This does very little to convince me that the CacheServer proposal should be used for databases.
So let's implement CacheServer for package files only as described in FS#23407.
Apply my patch anyway to make pacman happy with pacredir. :)
Now that pacman 6.0.0 is in [core] we should have an idea of a solution at least. Given that a number of caching solutions exist [0] having the header solution around may be not the worst idea. So does this have a chance to be committed?
Andrew already gave it a -1. That means there is zero chance of it being committed.
Still the CacheServer directive for package files would not work with database files. Thus it would not be a real solution for use with pacredir. So would you accept a patch to disable the server error limit from configuration and command line switch? That would kind of resolve the issue but result in error messages still being thrown for me, however... Had hoped to get rid of that.
Going through other caching solutions, CacheServer ignoring missing packages would solve most issues. So I'll implement that when I have a spare 30 minutes. Once that is done pacredir can probably do "pacman -Sy; pacman -Sy; pacman -Su" as a workaround until we handle dbs too. Allan