To summarise, the main data we need to store are - files currently used by freenet, to be updated - bin : /proc/pidof(wrapper)/exe and something similar on windows probably - lib : lib in wrapper.conf - jars in wrapper.conf - files needed by new-freenet[1], to be downloaded and added to wrapper.conf - bin : manifest, with acceptable version-ranges (e.g. >= 3.4, << 3.7) - lib : ditto - jars : ditto - keep track of files downloaded (and not since deleted) by the updater - easy, just write a file, perhaps comments in wrapper.conf
the "binaries" and "libraries" could be implemented as you say by a manifest in freenet-ext.jar [1] we should store version RANGES to support the user using their own libs. so the actual list of files that we DISTRIBUTE needs to be stored somewhere else (but freenet does that already), and the updater needs to match those files against the acceptable version-ranges. On 06/04/12 20:16, Matthew Toseland wrote: > As I see it, the minimum functionality we need to split freenet-ext.jar is: > - A manifest file in freenet-ext.jar listing each, for other file that the > new freenet-ext.jar depends on: > -- The filename of the latest version of the file. (it will be stored in lib/) > -- The stem of the filename, for garbage collection purposes. > -- The SHA256 of the latest version of the file. > -- A CHK to fetch it from. > - The freenet-ext.jar itself would refer to the files in lib/ via the usual > Java mechanisms, so we don't need to update wrapper.conf, except to switch > from the old freenet-ext.jar to the new one. freenet-ext.jar is a secondary > jar and we don't use java -jar, so it's possible we need to update > wrapper.conf. If we do, we need to extend the wrapper.conf rewriter to > include the new jars, whether or not prior versions exist already; provided > the filename stem's don't overlap, this is fairly straightforward. > - We do not need radical changes such as calling out to a script to replace > everything and restart freenet, because we are simply restarting with > different files - we never need to replace anything. > - Filenames always change when the file contents change. If they are not > being updated, they will be on our classpath - we can ask the wrapper, or > read wrapper.conf. How will you handle the wrapper binary / libraries? The binary name is hard-coded into run.sh, and the library name is obtained by a search algorithm hard-coded into WrapperManager. > - After restarting, we can garbage collect in lib/ - identify libraries that > are older versions of what we are using now, and delete them. > We need to keep track of what we actually have downloaded, and *only delete those*. If the user edited their wrapper.conf to point to system libraries, we don't want to delete that when we download a new version. > So a relatively small set of changes allows us to split up freenet-ext.jar > properly: > - Create the manifest file in contrib (initially by hand). Update the build > scripts to include it in the built jar. > - Analyse it when we have a new freenet-ext.jar to deploy. > - Check the versions of the current libraries by asking the wrapper for a > list of jars loaded, or reading wrapper.conf. > - Any that are not loaded must be verified on disk. If they're not on disk > they must be downloaded. Once we have all of them we are ready to deploy. > - Do we need to update wrapper.conf? If so, changes must be made to support > patching in the new versions of jars (and the new jars). > - Garbage collection is an optional extra. > > There are several further complications: > > 0. Installers > We can easily include more files. This is not a big deal. > > 1. update.cmd and update.sh > These will need rewriting so that they can download all the new files, when > run from old versions. This is easy-ish on unix but somewhat less easy on > Windows. > > 2. Updating the wrapper itself > We have to update the wrapper jar at the same time as the wrapper binary, and > can't do the latter while the node is running. So we will need to download > the new wrapper files, then start a script, which waits for the node to shut > down and then substitutes all of the new wrapper files, and then starts the > node back up. > > IMHO this does not involve a fundamental reworking of the updater, and in > fact, it can be implemented in stages if it's useful to do that. > > > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20120407/c98868c3/attachment.pgp>
