I actually considered this a long time ago. Simple solution is to bundle rsync with wpkg and allow one to specify a remote rsync location to retrieve packages. When this attribute exists, wpkg simply syncs a local temp directory with the specified one (perhaps resuming where it left off), and when complete, issues the install command.
That rsync location can be either a single file off http, which rsync already supports, or an rsync server hosting many software installs... or even a smb path, which rsync would just copy from. Wpkg doesn't have to implement anything protocol specific at all. Simple addition, actually. On Wed, 2006-04-05 at 11:37 +0200, Jérémie wrote: > Tomasz Chmielewski a écrit : > > Jérémie wrote: > >> Michael Chinn a écrit : > >>> At present I have added packages to wpkg using bat & perl scripts > >>> that download a zip of the program, check the MD5, extract, run and > >>> then delete the zip/temp files. This allows for disconnections during > >>> installations, partially downloaded files fail the checksum and are > >>> downloaded again until they work. That got me thinking if some of > >>> this functionality could be incorporated into wpkg directly, > >>> specifically the MD5sums of the installer command (I use the gnu > >>> md5sum.exe port). I would offer some code however my knowledge only > >>> extends (at the moment) to bat files and perl. > >>> > >> > >> That'd be _really_really_ cool ! Both with http(s) support, we'd be on > >> the way to "winapt" ;) :P > > > > Hmm, interesting idea. > > > > Sounds like we could do: > > > > wpkg /update_sources - to update package definitions > > /me so excited ! :D > > > wpkg /install_web acrobat_reader - to install packages off the web > > I'd better have a sources.xml defining where to find package sources, > and maybe thus providing a normalized way to define package path. Then > whatever the sources you defined (smb, http or any other in the future), > you would still use the same ''wpkg /install'' command. > > > However, I think perl installation would be an overkill for that. > > +1, one nice thing with wpkg is that it has "no" dependencies provided > your windows setup satisfies to very few requirements. On the other > hand, this may lead to "reinvent the wheel" if Perl could already > provide usable code... > > > Probably we could use some Cygwin tools like wget, md5sum, unzip etc., > > installed in \\server\wpkg\tools? > > When I think to internet based deployment, a la apt/yum/urpmi..., these > mandatory tools may be bundled with wpkg in a (silent) installer so that > "isolated" hosts can be autonomous and pull their updates straight from > a web server > > Very Bests > Jérémie > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 > _______________________________________________ > wpkg-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wpkg-users ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ wpkg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wpkg-users
