distributed updates are alive
I was able to sit down and look through the dependency retrieval code of autopackage’s support code. The short story is that I put together some logic to use an application’s luau xml repository file to search and install a .package . The long story is that there were logic issues with the existing code so at least this exposes a code path that was not being used at all.
The update service will become another component of rootname management. The package (rootname) database holds information about the project’s rootname and current release. The rootname table should closely match the project’s apspec file. A master file would be downloaded to search for a project name and quickly see if an update is available. If you continue the process, the luau downloader will obtain the project xml repository to find where to download the .package. The downloaded .package is executed like a typical install session sequence.
Scenario:
`package search gaim’
download master package information list
try to match shortname gaim against master package information
if match found - check for update against SoftwareVersion (and future PackageVersion)
if update available use repository uri to download .package meta
install .package
I will update cvs with a patch to correct the logic issues and submit the new logic patch to the ml soon.
January 5th, 2006 at 9:27 am
It’s cool that we’re getting something like that, “package search” seems cool particularly. On the other hand,I don’t understand why auto-update needs to refer to a central package list anywhere. This goes against our philosophy of distributed design.
IMHO the right way to do auto-update is to simply have a package embed a URL to its XML file in the package metadata itself, so “package update all” can then try each one in turn. Long term of course this would be done in the background by a helper program every few days so the user would never have to remember to do it (and it’d have a nice GUI etc)
January 6th, 2006 at 11:31 am
Hey Mike,
Well you are correct, my explanation does combine the search and update function. That is my mistake. Yes, adding a Repository meta key for an application _is_ the correct way to bootstrap an update session.
I will probably add a wiki entry about the requirements. I have logic that does the update and search function. We just need to get luau to download the highest software version and package version. I believe that this will be a new function for luau so it will take some time to see this available.
Synopsis:
Search function can be added at any time. Update function is blocked by required function in luau downloader.