The current plugins installer script written by BuildContrib has a major flaw; it doesn't correctly upgrade topics. At the moment it simply writes the new .txt file into the web, in the hope that the installer (person) will subsequently check the new versions in. It has to do this because the installer can't override the locks that the apache user has on existing topics, and even if it could, that's a horrible hack :-(.

Some options

Use LWP/curl/wget

On Tuesday 25 January 2005 19:58, Peter Thoeny wrote: > this problem can be solved if TWiki has a web based
> interface to update topics by a script. E.g. if you
> run an install script as user jsmith, the script
> installs the Perl scripts as user jsmith and invokes
> a URL that updates the topic as jsmith via web
> interface, e.g. Apache user. That way access control
> is handled correctly as well, e.g. jsmith needs to
> be in the TWikiAdminGroup if the topic is edit
> restricted as such. In addition, the Apache lock is
> correct as well.

However this is not reliable. I have encountered several environments where command line internet access is not available, or is only available to super users (including at least 2 hosting providers I have seen). This is why the current install script allows the install to proceed even when there are unsatisfied dependencies.

Install from the browser

Personally I'd far rather there was some way to do the entire install from the browser. For example, imagine a plugin install page/script that

1. gets the zip from twiki.org
2. unzips it in a neutral directory
3. checks & offers to satisfy dependencies
4. moves code into $twikiLibDir
5. moves pub into $pubDir (6) moves data in $dataDir, and checks it in (7) removes the temp dir

all from one button-press in the browser.

e.g.

---

You have chosen to install ActionTrackerPlugin

Please wait a few moments while I fetch the package from TWiki.org....
Download progress 100%
Checking ActionTrackerPlugin dependencies...
I notice you do not have CPAN:Time::ParseDate installed. This is required for the ActionTrackerPlugin. Would you like me to try and install it?

clicks

---

Sorry, I couldn't download Time::ParseDate. Here's the reason:
blah
You will need to ask your sysadmin to resolve this problem.

clicks

---

Checking ActionTrackerPlugin dependencies....
I notice you do not have AttrsContrib installed. This is required for the ActionTrackerPlugin. Would you like me to try and install it?

---

You have chosen to install AttrsContrib

Please wait a few moments while I fetch the package from TWiki.org....
Download progress 100%
Installing code modules
Installing topics
Installation complete. Click here to return finish installing ActionTrackerPlugin. clicks

---

Checking ActionTrackerPlugin dependencies.... OK
Updating topics.....OK
Installation complete. Click here to go to the ActionTrackerPlugin topic to complete the configuration.

---

Smarter command-line script

With DakarRelease the default locking behaviour is probably changing so that the apache user doesn't have permanent locks on all the RCS files. This means that the installer can easily check in new revs of topics as themselves. This is probably the ideal solution, but it just doesn't hack it for older TWiki releases

Any other ideas? Opinions? Code?

-- CrawfordCurrie - 26 Jan 2005

Rather than worry about locks I'd focus on getting Dakar to work. Most people doing subsequent installs are reasonably technical so a mention in the release notes would probably suffice.

-- MartinCleaver - 27 Jan 2005