You could base whether you run the script or not on the current version of foresight/group-dist, and the version of whatever components are affected. That way it's only run when the troves in question undergo the same update you wrote the script for, avoiding any possible issues with late updaters/people with unusual packages. This would not much affect removing kernels - except maybe removing a kernel only once the version of the OS is high enough, but might be a very good idea if such scripts are used for other things
On Wed, Jun 18, 2008 at 6:58 AM, Ken VanDine <[EMAIL PROTECTED]> wrote: > We should also have some identifier so the same script doesn't get run > twice. Perhaps a comment in the file that points to an ID. > > <snip> > #id 5 > </snip> > > Once the script is run, we touch a file in some > directory /var/run/tidy/5 perhaps. Next time we fetch the same script, > we check the id before running it and see if the file exists. > > --Ken > > > On Wed, 2008-06-18 at 00:39 -0400, Michael Tharp wrote: >> Ken VanDine wrote: >> > Good point, pulling from hg might be nice too. However, rss means >> > someone has to make the conscience decision to publish the scripts >> >> RSS doesn't seem like a really good fit here since you'd have to >> post-process it on the client side. With hg, you could just point >> clients at a particular file in the repository and fetch it with wget or >> curl or python's urllib. >> >> > This could be accomplished with a mercurial tag or using a separate branch >> > and merging over to the main branch when they are to be released. >> >> Branch would be best here; tags are supposed to represent a fixed point >> in time even though you can technically "move" them. >> >> The problem with mercurial though is that the HTTP approach only works >> for a single file and it's slow since the CGI script has to conjure up >> the contents of the file on the fly. >> >> Here's my suggestion: have a hg tree with many scripts so that it's easy >> to maintain. Keep it in the usual location, on hg.foresightlinux.org. >> Then, make a checkout of it on a webserver somewhere, and configure it >> with commit hooks so that whenever anything is pushed to it (the >> checkout, not the main repo), it updates and concatenates all the >> scripts together into a single static script. The static script would >> then be the file that clients fetch and execute before updating. The >> number of people with access to the webserver could be a subset of the >> people with hg access, and whoever does the push has an opportunity to >> test them before doing so. >> >> You could have a script like: >> ---snip--- >> #!/bin/bash >> hg up -C tip >> cat preupdate/*.sh >/srv/www/foobar/preupdate.sh.tmp >> mv /srv/www/foobar/preupdate.sh.tmp /srv/www/foobar/preupdate.sh >> ---snip--- >> and make that the "changegroup" hook (I think), and it should keep >> itself up to date and rebuild the script whenever anything is pushed to >> it. Naturally, we'd want to sign the resulting script with PGP and >> verify it on the client side, or something along those lines, to prove >> to the tinfoil-hat types (including me) that the script probably isn't evil. >> >> -- m. tharp > > _______________________________________________ > Foresight-devel mailing list > Foresight-devel@lists.rpath.org > http://lists.rpath.org/mailman/listinfo/foresight-devel > -- Jack Doerner There are worse crimes than burning books One of them is not reading them. -Joseph Brodsky _______________________________________________ Foresight-devel mailing list Foresight-devel@lists.rpath.org http://lists.rpath.org/mailman/listinfo/foresight-devel
