Forum OpenACS Development: install from repository admin

Posted by Mark Aufflick on 10/20/03 08:01 AM

just an idea for discussion (after my confusion surrounding the repository install indeuced mostly by not reading what i click)

should the repository install menu be second on the page (after file system) and should the user get more feedback about what is going on (ie an interim page saying "i am about to contact the repository over the internet - is that ok yes/no")

also a nice option would be something like an upgrade page saying "you have weblogger 1.0 installed - would you like to upgrade to weblogger 1.5 from the repository?"

just thinking out loud...

2: Re: install from repository admin (response to 1)

Posted by Lars Pind on 10/20/03 08:13 AM

Mark,

There's definitely room for improvement.

Here are some of the thoughts behind the current design:

1) The reason I put repository install up top is that the goal was that non-developer users would download a tarball of acs-core, and that their primary path for installing packages would be from the repository.

The only people who'll want to install from file system are developers who develop straight off of the openacs CVS tree, or developers who have a local repository set up and install by checking out from openacs cvs, importing into local cvs, then updating. In other words, the only people who will be installing from local file system are people who full well know what they're doing.

2) I've seriously considered merging local install and repository install, so every time you want to install packages, we look both at the local file system and in the package repository for uninstalled packages.

Only tricky point about this is, what if you have an upgrade sitting in the file system, while there's an even later upgrade sittingn in the repository? What should we do then? That's a quite likely situation, actually.

/Lars

3: Re: install from repository admin (response to 2)

Posted by Mark Aufflick on 10/21/03 02:55 AM

I think the thing that does not want to be merged is installs and upgrades - people will end up upgrading when they don't want to.

if there was, for eg., a seperated "search for upgrades" link, then you could list all available upgrades - grouped by package. The repository could even offer multiple versions. Let's say we're in the year 2006 and someone has 5.0 installed, they would see half a dozen available upgrades, and they may want to only upgrade to version 5.2 for some reason.

for the install - good point. maybe the install from file system could even go into the developer admin page....