Forum OpenACS Q&A: Design of an "Automatic Software Update Service"

6) What happens if there is custom code. Currently the APM approach will overwrite any custom code and it's gone. As for CVS, it might generate conflicts. You could do a check if any files in the package you are about to update have been changed and if yes send the administrator a notification that the package is available for upgrade, but can't be upgraded due to changes made locally (similar to how apt-get works).

7) We have a tendency of not being very good with releasing packages, as it requires to retag the package every now and then. So the APM approach would require the developers to tag packages on a regular basis. On the other hand, if you go with the CVS approach, you might break your site even in the "stable" tree, because you are updating without dependencies (as you might depend on a function in the kernel that has been added but not resulted in a new release of the kernel package).

My recommendation therefore is this:

- Add a "sources" repository to the APM which is a list of repositories where APM can retrieve the files from.
- Use APM files instead of CVS
- Check before the upgrade if it is safe to install (we should be doing this anyway)
- Write a collector that retrieves the CVS messages between the previous release and the current one and stores them in a file "latest_release.changes" that is displayed to the user before upgrade.
- Write a TIP for it.
- Collect gratitude :).

I don't think a rollback will work, especially not an automated one. For sure you could execute a database backup in advance, but do you really want the users to loose their data because of an upgrade they did not like?

So yes, I do like your idea, but it is not the piece of cake as it might sound.

Digressing on the G-ETP idea a bit further..

..instead of copying the .tcl from the package-key/www, a tcl file in the serverroot/www tree could probably (untested) source the original, and include new variable calculations etc so that most changes via apm will automatically update the tcl, too, while retaining customized tcl code.

# foo.tcl
# calculations before sourcing original file (if any)

# source original file
source /var/lib/aolserver/service1/packages/package-key/www/foo.tcl

# calculations after sourcing original file

just to let you know: We've implemented two new packages "intranet-update-server" and "intranet-update-client". This combination is really only a convenient frontend for CVS. The server sends a list of update options the client together with some suitable CVS commands that are executed on the client side.

- The server part provides a XML file with information about available updates.
- The client part parses the XML file, shows the content as a HTML table and does a "CVS update -r Xxxx" or whatever as specified in the

That's it. Using CVS allows to have some(!) changes/ customizations on the client side that might survive an update. That's not perfect but it's already something.

Somebody interested in the code? The code is going to be part of Project/Open V3.0.0 which is going to come out hopefully(!) this weekend.

Bests,
Frank

well, we send an "hand made" XML file to the intranet-update-client which is rendered as a HTML table.
So the user can actually decide whether to upgrade his system.

Also, we want to use the system to announce the availability of new modules (such as the wiki module recently), so that we woudln't always want to update every user to every available update.

So the process is basicly manual and gives the decision power to the user. That simplifies the code and is sufficiently flexible to deal with all kind of strange exceptions etc.

Bests,
Frank

I understand your points, believe me.

How is the user going to make an informed decision

Every update option has a link to a specific Sourceforge forum where users can discuss the upgrade amongst themselves or give their opinion after a (hopefully!) successful update.

This is considerably less maintenance than releasing
packages and storing release notes with them. Furthermore
it gives you the flexibility of not having to release so
often :).

Good thinking. I had some very similar thinking ... 😊

Check it out:
http://www.project-open.com/product/services/software-update/.

You will see that our design is very much covering your points. However, we can offer the user to perform "major updates" of the entire OpenACS system (like: "cvs update -r openacs-5-1-5") AND we can offer the user to install a new package (like: "cvs checkout intranet-wiki").

Obviously, any Linux admin could execute the same commands manually via CVS. However, we at Project/Open have to deal with "technically interested users" who generally don't even know about the existence of CVS... So this is also why we are going to ask for money for this service.

Checkitout man, checkitout,
Frank

How should I check it out?

I meant: Just check the link out, which will lead you to our marketing blurb about the service, which includes a screenshot. This screenshot should explain everything.

provide under the GPL

No problem with the GPL. You can grap the current code and release it under the GPL. We are going to sell the _service_ (i.e. the service of providing an updated "hand made" XML file), not the code. Both modules ("intranet-update-client" and "intranet-update-server") are available on our CVS:

cvs -d :pserver:mailto:anonymous@berlin.dnsalias.com:/home/cvsroot checkout intranet-update-client

upgrade based on DIFFS

Just add this to the existing stuff. Our code is pretty small and straight forward, some 1200 lines in total for both modules. We are not going to use this for our customers, because "diff lines" would just scare them off ... 😊

I hope this could become a reasonable contribution from us to the OpenACS community, together with the Windows installer.

Bests,
Frank