On second thoughts, the more simple solution is to have the manifest of "bin/lib/jar file-version" in a separate file in the update directory on freenet.
This information should *NOT* go in freenet-ext.jar. The reason is because it's distribution specific, and other packagers (like me for debian) might use other versions of the files that work fine. That's why I suggested the "version-ranges" information, which could be in freenet-ext.jar. But currently I don't see a use for it, and it would make things more complex. TL;DR: your idea of the manifest is OK, but this information should NOT be inside freenet-ext.jar itself, it should be a separate file that gets distributed to the update directory, that the updater code reads first. I can add such code to contrib-staging soon. A new target in build.xml that creates e.g. freenet-default-install.mf will do. X On 07/04/12 13:35, Ximin Luo wrote: > 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 > > > > > _______________________________________________ > 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/45849d9a/attachment.pgp>
