Great work Micheal! The whole process is much smoother; I only have one significant problem now for cygwin.

• uname for my machine, windows2k, is CYGWIN_NT-5.0 ,copying the 5.1 sample config to 5.0 worked as is
• logfile: marking the start and stop points for each script would make it a lot easier to troubleshoot problems
• integrateWithApache.pl: sub getServerUserGroup grep search for ^User also matches UserDir directive, making later chown operation fail. Also this sub is duplicated. The second copy is shorter than the first. both fixed in cygwin-matt.patch

The remaining problem:

patching file TWiki.cfg
Fixing permissions, ownership and updating symlinks
ln: creating symbolic link `Example' to `../../webs/Example/templates': Permission denied
ln: creating symbolic link `Main' to `../../webs/Main/templates': Permission denied
...etc...

-- MattWilkie - 22 Jul 2003

Can I PLEASE request that "bug reports" and feature requests be moved onto TWikiUnixInstallerPerceivedIssues. Can I PLEASE request that comments regarding a TWikiUnixInstaller for Windows be made on the TWikiUnixInstallerWindows page ?

Whilst I have made a couple of cygwin friendly tweaks to make it work better under cygwin, the installer is not designed, nor originally intended for use on Cygwin. You would also note that regarding the "chown" issue - I view this as a cosmetic problem which I am not going to fix because it's necessary under most Unixes, even if Cygwin is a completely broken operating environment.

Regarding the uname problem - this isn't unsurprising. I wouldn't be shocked if different service packs cause this to break. The current approach is intended as a one off stop gap to make life easier until the rewrite into perl has been done.

• uname for my machine, CYGWIN_NT-5.0 ,copying the 5.1 sample config to 5.0 worked as is

FWIW, I'll be ensuring that this small change is included. (Indeed have done, I just haven't uploaded the new version yet)

Regarding the ln issues you are seeing I do not see this using an unmodified version of the installer. Are you using a standard version of the installer?

Using a patched version of the installer is recommended against, and I will not support the patches Martin's listed (comment & patches now on TWikiUnixInstallerWindows) as I told him in email before he posted them here .

Regarding the sub duplicate - good catch - I hadn't realised I'd done that - thanks!

-- MichaelSparks - 22 Jul 2003

1. The patch I uploaded would have solved Matt's uname problem as well - it would mean that he could have supplied a config file next to the bootstrap.sh file. This has nothing to do with my use of WindowsApache
2. I got the ln issues even when running your unmodified installer using your standard config file.
   • I suspect that it is something to do with the machine not being a clean install - I've found that I already had a d:/twiki directory, for example.
3. I know that you just dislike Windows and prefer that TWiki run only in Unix like environments, but as you mentioned yourself on TWikiIRC TBH if I was in a Windows "shop" I'd run IIS/ActiveState perl rather than cygwin/apache)
   • Hence, so that someone else can pick up the code as it develops further and add in the necessary parts to make the installer work with native Microsoft things, I would appreciate if you could arrange for handlers to be added at strategic points (in the interim at least at the beginning and end) to that provide different functionality.
   • Eventually it would be sufficiently elegant to allow the overriding or supplementing of any step, but frankly that is overkill for the short term.

-- MartinCleaver - 22 Jul 2003

> as you mentioned yourself on TWikiIRC
This is incredibly rude behaviour. IRC is treated as an ephemeral environment. Would you wish me to post your private mailings? (Such as those which have made myself and several others extremely uncomfortable to be on the recieving end of?) (I'd not about to do this, it's a rhetorical questions)

> prefer that TWiki run only in Unix like environments, but as you

I've not said that . I've said that I won't write an installer for an OS I personally find incredibly clunky and inefficient, but great as a DVD player. (See the TWikiUnixInstallerFAQ) Your patches are suitable for a windows platform, so I've moved them to a page where someone interested in writing an installer for windows (which as I stated should be IIS/Activestate Perl IMO) can take that forward.

You are successfully encouraging to cease all further public work on the Unix installer. I have said many times that I will not be accepting patches to the Unix installer to deal with Windows. Windows deserves a native installer.

Quite frankly I'm beginning to regret releasing this code.

-- MichaelSparks - 22 Jul 2003

Michael, it is not my intention to cause offence in this matter. If I have offended you I apologise. My interpretation of your opinion of Windows is my own, I apologise for putting words into your mouth.

WRT to TWikiIRC, it, like TWikiDotOrg, is a public forum. Furthermore it is archived on the web so the discussions are neither private nor transient.

The patches I submitted dealt with a general case of wanting to override the twiki.system-config file, they were not specific to Windows.

-- MartinCleaver - 22 Jul 2003

Re-iterating what I said in email:

Date: Mon, 21 Jul 2003

You're getting closer to the way I will be doing it, but you're not there yet. Before I make the changes though I'll be changing to a perl script for the bootstrap installer rather than shell script. (Largely because the changes I'll be making are best done in Perl anyway)

I could make the things I need to work, work in shell script, but there's a high likleyhood that rather being sh friendly (and hence fairly Unix agnostic) it'd become bash (or ksh, or...) specific which reduces the agnosticism of it. Rather than put bad * patches in I'd rather change it to something better. After all currently the system works.

 

* NB by "bad" I mean anything that increases the logic being done in the shell script - which becomes increasing convoluted with time by very definition. (I'm not talking code quality)

I can for the moment add in an extra default config file for that version of cygwin. (And I can keep on doing this happily for a while since it's a more elegant (not elegant, just more elegant) solution than constantly changing code.) ...

Date: Mon, 21 Jul 2003 12:28:28 +0100 (BST)

> 1) I'd still like to be able to override any default set with specifics supplied in a config file.


This has been planned for all along. Part of the point of having a config file in this format in fact. My preferred manner for installing systems is in a headless mode (jumpstart, kickstart, alice, etc) and that requires a sh scripting friendly environment.

I knew I shouldn't've done a release of the code before including everything I wanted to & doing the rewrite into perl.

I really don't know how I can make it clearer that uploading patches isn't a sensible thing to do when the code structure will change underneath people rather dramatically invalidating the patches probably within hours of you uploading them. (And then people will ask me why their patched installer is busted)

I'll be editing out this conversation shortly to TWikiUnixInstallerDiscussion since it's not productive, and is IMO obstructive.

-- MichaelSparks - 22 Jul 2003

1. I've moved the conversations to the said topic - I hope you find this agreeable.
2. I've always thought that the point of things here in Codev was to have rapid developer-oriented discussions. Its kind of natural if we end up throwing away implementations, I was trying to evolve the codebase rather than just contribute words. If the patch I uploaded lasts 2 hours or 3 days that's fine by me, I just thought it might help someone.
3. For some reason I had not read the 2nd half of your email - sorry about that. As for users on x86 switching away from Windows this is simply not a possibility in many environments, so while they might get a 3 fold increase by switching to linux in practice the best they can do is get a 30% increase by using Cygwin with WindowsApache instead of Cygwin with CygwinApache.
4. If people add my patches and it breaks that's my responsibility. I don't think anyone would question that. If my patch breaks your installer they should come to me if the patch was released since your version or fix it themselves if they can't wait for me to update the patch or you to incorporate it. A patch is not your responsibility unless you roll it into your next code release.

To clarify: I don't expect you to support WindowsApache but I felt that it was not much to ask to accomodate the non-windows-specific patch to help people who need to alter your defaults.

I know TWikiUnixInstaller is a good working prototype and I know you have a limited timeframe in which to complete it. I suspect that it will not get altered after you put it down so I am trying to ensure you get a chance to collect as much requirements gathering as inputs into the design as much as possible and as soon as possible.

If nothing else, being aware of diverse requirements will lower the cost of making such changes later.

Lastly, is this the wrong time to request that it would be nice to be able to specify where the perl executable is? My linux hosting provider has it in /usr/local/bin, it would be nice if that went into twiki.system-config.

Regards and thanks. M.

-- MartinCleaver - 22 Jul 2003