On Wed, Nov 12, 2003 at 05:39:59PM +0100, Darian Lanx wrote:
>
> First of all, thank you for adding this Rob, but there are a few
> concerns I have.
>
> 537 # If there's no TIMESTAMP file, then we haven't synced
> from rsync
> 538 # before, so there's no checking we can do. Blaze on past.
> 539 if ( -f "$descdir/TIMESTAMP" ) {
> 540 open TS, "$descdir/TIMESTAMP";
> 541 $oldts = <TS>;
> 542 close TS;
> 543 chomp $oldts;
>
> While this makes sense it introduces a logical problem. Because ideally
> the code would simply reject the mirror if there is no timestamp
> present. why? Well our policy states that the mirror may only sync the
> timestampt AFTER all of the info files were synced successfully. So if
> there is no TIMESTAMP, something has gone wrong on the mirror and we
> should not poll any data from it.
This part of the code is checking for the timestamp on the local machine,
not the server. If it doesn't exist on the local machine, it's probably
because we haven't run a version of fink that did the timestamp checking.
This isn't an indication of anything being wrong on the server side.
> Furthermore on:
>
> 609 $cmd = "rsync -az --delete-after $verbosity $nohfs $rinclist
> - --include='VERSION' --exclude='**' '$rsynchost' '$basepath/fink/'";
>
> and on
>
> 533 $timecmd = "rsync -az $verbosity $nohfs $rsynchost/TIMESTAMP
> $desc dir/TIMESTAMP.tmp";
>
> While I do notice that the files are written into different locations,
> would it not be better to simply do:
>
> "rsync -az --delete-after $verbosity $nohfs $rinclist
> - --include='VERSION' --INCLUDE='TIMESTAMP' --exclude='**' '$rsynchost'
> '$basepath/fink/'";
>
> While that might not be the actual command or line it is at, my point
> is. Even if we do not decide to use the mirror we pulled the TIMESTAMP
> and VERSION file from, we do safe us a system() call and a rsync
> connect. To unlink the VERSION should be drop that mirror because of
> TIMESTAMP issues should not be time consuming.
No, this can't be done in one rsync. The problem is this:
If we pull down the timestamp file with everything else, then do the
compare, we may have just trashed our .info files. We need to pull
down the timestamp first, compare, decide if it's safe to pull down
the .info files, then do it. I've been trying to think of a way to
do it in a single rsync that 1) doesn't pull down the entire tree
more often than it needs to, and 2) doesn't trash your files. I just
haven't come up with a way yet.
Doing this in a single rsync is preferable not just for speed reasons,
but it enables a whole host of other possibilities.
> And just a question:
>
> 561 # error out complaining that we're trying
> to updat e
> 562 # from something older than what we
> already have.
> 563 unlink("$descdir/TIMESTAMP.tmp");
> 564 print "The timestamp of the server is
> older than w hat you already have.\n";
> 565 exit 1;
> 566 }
> 567
> 568 }
>
> once that is executed, does it throw the user back into the "choose
> another mirror" routine or does the user have to type fink selfupdate
> again ?
As you will see, there is currently no mirroring support at all in
the rsync code. So, no, this doesn't throw the user into a choose
another mirror routine. It simply exits.
However, I am about to commit a bunch of code that does enable
mirroring for the rsync updates. Please be patient.
> My idea is, that there is some function like &get_next_mirror_from_group();
>
> That way the logical flow is as follows:
>
> Look up in fink.conf what is set e,g, eur-DE
>
> look what is in eur-DE pick the first mirror.
> check if the mirror fails
> if so, pick next until the end of the mirror list is reached or success.
> once the end of eur-DE is reached without success
>
> dump the user into
> "Which mirror would oyu like to use all your countries mirrors failed"
I have done my best to have the rsync mirroring code use the
same system as the distfiles. I don't see much point in duplicating
a site mirroring system for each transport mechanism. Once that is
in, you can start discussing any changes you would like to make to the
fink mirroring code in general terms. It should be there soon.
Rob
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
