On Mon, Jul 10, 2006 at 04:15:58PM +0200, Michael Schroeder wrote: > On Mon, Jul 10, 2006 at 04:02:00PM +0200, Robert Schiele wrote: > > 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.
Sure this was mainly due to a bug. But what do you expect? That you never hit any bug in the future again? It is the whole idea of eliminating single points of failures to prevent suffering from _failures_ too hard. > > 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. Well, if it finally proves that my idea was completely crap then we could easily remove this file again. But not even trying it just because there _might_ be a problem does not really make sense if the is no big risk involved. > > 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. Well, ok, maybe this is the source of some misunderstanding: My idea was to create this file immediately when creating the repository (on the same system that creates files like INDEX.gz or ARCHIVES.gz). In that case the file will be always in sync with the repository at any time a mirror sync is complete. Sure the file _could_ be also generated by the drpmsync server but I would recommend to decouple this completely (besides the fact that code might be shared and that the actual client makes use of the deltas generated by the real drpmsync server) because this file describes only states of the files contained in the repository. The logic how to use this information to apply patches is completely up to the client implementation. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:[EMAIL PROTECTED] "Quidquid latine dictum sit, altum sonatur."
pgp68vxHy7eNs.pgp
Description: PGP signature
