David Walser wrote: > Buchan Milne wrote: >> On Fri, 4 Apr 2003, David Walser wrote: >> I would be more interested in config files and multiple source support (I > > Well the current script is just a front end to rsync. It's basically just rsync + > RPM file migration and renaming (it can migrate packages from cooker to contrib and > vice versa w/out deleting and redownloading). > > It would make more sense to accept rsync command line options and be compatible with > that. > > Another script that could be a front end to this, supporting config files, might be > interesting/useful. Multiple source support would be good too, since you currently > have to make new copies of my script for each distro you use it for (aka Cooker, > 9.1, and 9.1 updates are all different distros).
Well, I suppose it could support config files, but I don't want to overcomplicate the script too much with so many ways to get its configuration. Actually having command line option support is as good as supporting config files, because your "config" file could be your script that runs cooksync, using whatever options you want for each run. That takes care of multiple source support too. >> will probably use it now for updating jpackage and plf, since I have local >> cooker mirrors, but jpackage and PLF I currently rsync over dialup. > > Yeah dialup, that's how I spend most of my time using it. It definately helps with > the bandwidth it saves. > > I supposed I shouldn't call it cooksync, because as you point out it works for more > than Cooker. It in fact should work for any RPM repository where RPM filenames are > in the standard format (so it could work for RedHat Rawhide). So I've renamed it to rpmsync. http://luigiwalser.homeip.net:8080/~david/rpmsync.pl the last version of the script is available as cooksync. >> BTW, how's this for an idea: >> -Be compatible with urpmi, making a local (file://) urpmi source >> -adding a config option for the urpmi source with the details needed for >> rsync, urpmi.mirror (does this conflict with Olivier's sutff?) would >> update the local urpmi source via rsync, then update urpmi's hdlists >> (urpmi.update) > > Well, I currently have the Cooker mirror, and the urpmi that's using it on different > machines. The Cooker mirror is a network source. I think more people would be > using it like that than having say, the Cooker mirror on a running Cooker machine > itself, though the idea of having it automatically update the urpmi source is > interesting. > >> This would be useful, since most uses of this script would be mirror >> urpmi-enabled rpm souces? (And if not, urpmi could ignore them?). > > Not necessarily, but even for cases where it is, I think in most of those cases the > mirror and the urpmi are on different machines. > >> Then all it needs is a gui. And when fpons gets to adding something like >> --repackage to urpmi via rsync, we already have some code/experience in >> place. >> >> Regards, >> Buchan > > Yeah, my code may very well help with that (the --repackage thing). Your ideas > about it automatically updating the urpmi source at that point become much more > useful/interesting. > > I'll start (when I get a chance) with adding support for rsync CLI arguments, and > I'll let you know when that's done, then we'll see where you want to go from there. Ok, that's done. Most of the command line options resemble rsync's. Once a bug is fixed in Getopt::Long, you'll be able to run it with rsync command line options, and it'll just ignore ones that aren't options to my script (silently if you redirect stderr, unfortunately you can't configure Getopt::Long to silently ignore them). So what that means is you'll be able to use it as a drop-in replacement for rsync. For now if you only use options provided by the script, you'll surely be fine. The script can still also be configured by editing the definitions at the top of the script; those are the "defaults" of the script now. Unfortunately, adding command line option support means I had to change them from constants to variables, so you'll lose some microseconds of execution speed :o(. One cool thing is, the help output says which options are set by default, and that help output changes accordingly when you change the defaults at the top of the script. >> Don't you know Mandrake provides free hosting for small scripts, with free >> CVS support ;-)? >> http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/contrib-SPECS/cursor_themes/choose_cursor?rev=1.1&content-type=text/x-cvsweb-markup > > Which I'll get if I make a package for contrib :o) I guess I should do that. My todo list for the script really has 2 more things. One of them was adding support for a few more rsync options; I actually wanted to do that before adding command line option support, but I decided against all of them for now: --backup/--backup-dir - just no good way to do that --max-deletes - don't feel comfortable adding that. If someone wants that, they can add it to the definition of the $rsync_long_args variable. --compare-dest/--link-dest - just can't figure out how they work. I did some playing around with local files, and they appeared to do nothing. Maybe you need to use an rsync server. I tried running one as user, didn't work, didn't bother trying as root. The other was making it so the script could run the part that moves files around before running rsync on each source. That's important, because if your first source takes a while (say it's contrib) by time it gets to the next source (say cooker) some things may have been updated/moved around, and there would be benefit to moving some more RPMs around. Going along with that would be having it sorta looping through the sources until you're fully up to date. >> You may get more patches by putting it in contrib (not from me though, >> perl is greek to me ;-)). >> >>> I was actually thinking about >>> that a few minutes ago. I think I should add rsync command line options >>> support first before doing that (will take some work, probably won't >>> happen all that soon). I wasn't lying :o) It took 2.5 months to get around to it. I did all the actual work yesterday. Sorry about that.
