My gripe with NSIS is that to do user input, you have to copy over a DLL and INI file which communicate with the main installer's (ugly) scripting language by writing and parsing the INI file. It also seems to require you to hardcode the exact coordinates of each input field - so hope the user hasn't changed their default font or language. It seems like such a horrible hack that I was convinced there must be a better way.
I was hoping to avoid moving to a Windows-based solution so that the Linux and Windows builds can be generated by the same process, but today I gave up and started reading about WiX, which generates MSI installers. It has a nice logical XML format and real scripting language, so I was hopeful.
My first observation is that anything not provided by default, including simple text input fields, has to be done through scripting, and it suffers from the same problem as NSIS: you have to specify absolute positions for everything.
My next observation is that the XML format requires you to list each installed file explicitly! There's no way to do a whole directory at a time, and EPrints has hundreds of files to install. There's a tool (heat) to generate this list automatically, but it's intended to be run once and then maintained manually. Without completely reworking the development system or writing tools to do this, it looks like MSI will be too unwieldy.
My best idea at the moment is to use NSIS to generate a trivial installer which doesn't prompt the user for anything. Configuring the archive options can then be done by a separate utility - probably using a GUI toolkit for Perl, which will be able to work most efficiently with the configuration files as they're all serialised Perl hashes.
