On Mon, Jul 10, 2006 at 04:02:00PM +0200, Robert Schiele wrote:
You didn't get my point: I said that arguing that drpmsync should put its filelist on disk is like saying that rsync should put its (i.e. rsync's) internal file list on the disk.
The main problem with this is just that the data is outdated if there's an update just running, so you'll get a lot more errors about missing files than when the filelist is generated on the fly.
No. For the drpmsync server itself it is perfectly ok to create the list on the fly. But there should be a static version available for non-drpmsync-server systems. The argument that this might get out of sync does not really match here because getting out of sync is ways better than having no server at all.
But that was when the server was misconfigured. The cache file generation was broken due to a bad app armor configuration and the number of clients limited to two. Both things have been fixed last week.
Again: My proposal should not influence the way the drpmsync server operates at all. I intends to provide an _alternative_ way of doing things without doing any harm (but using about 3MB of disk space) to any other service.
Agreed, it wouldn't break things. I'm just a bit reluctant because of the outdated filelist problems, as already stated.
I would even provide a patch for the repository building scripts to do so but because they are prorietary (Yes, they are!) I cannot do this.
What do you mean? The repository is synced with drpmsync (and so the delta rpms are created). There is no secret script. The way to create the on disk filelist would just be another drpmsync call. Cheers, Michael. -- Michael Schroeder mls@suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org