Hello again, On Mar 30, 2010, at 23:36 , Alon Bar-Lev wrote: > On Tue, Mar 30, 2010 at 3:34 PM, Martin Paljak <mar...@paljak.pri.ee> wrote: >> On Mar 30, 2010, at 15:22 , Alon Bar-Lev wrote: >>> You can build one at [1]. >>> >>> http://opensc-project.org/build >> And the InnoSetup one linked from >> http://www.opensc-project.org/opensc/wiki/WindowsInstaller >> >> Alon, if you build a new one and upload it, please add a link to that page >> as well. >> > > Martin, > There is no point in two competing solutions. > As you very active, please decide which you wish to have. It is about what is the best/optimal solution that covers as many requirements as possible (if there are any) and that can also be implemented by someone in real life, not what I wish to have :)
Installers meant for end-users should do more than just unzip some files. There is no point in two competing *specifications* but until one of the implementations really is polished, there can be several binary "specification proposals" otherwise known as experimental installer executables. I personally prefer InnoSetup because: - IMHO it provides a more "Windows-like" experience (those annoying "add group for blabla" can be omitted and I assume unless putty-cac gets into the bundle nothing should be written to the desktop) - the installation script is shorter and easier to understand and easy to create for those who are not Windows-Installer-Savy - i know how to work with it But what is more important is a common ground on what the installer should do and how. I tried to write down what I think matters in Windows environment to WindowsInstaller wiki page [1]. Instead of two groupings there could be three: OpenSSL (mandatory) OpenSC and dependancies (could be omitted) engine_pkcs11 (could be installed independently from OpenSC) The structure of files in the installation directory should be set. If the result is built with native tools and with native conventions, a flat directory might be expected or just a few subdirs. Unix convention is OK as well but this is something that should be discussed. Registry keys involved need to be documented and well thought out what will be written and why. There's one key missing (or an alternative mechanism to locate profiles). Any modifications done in the user environment, if any, should be documented and made clear to the user. How the cardmod gets distributed and exposed to the user is also a question I have not thought about. What we've done in Estonia is an installer that "does everything that a normal user would want from the software to get the basic services up and running with Estonian eID and PKCS#11 software on Windows, which means Mozilla products". For such installer it was logical to cut all the unnecessary noise and install and change everything up to the contents of mozilla user profiles. But for a generic OpenSC installer some middle ground needs to be agreed upon. I believe there are many different opinions, so I'll say it upfront that my idea is to compete with the "official eID software" offerings in Estonia or for example in Portugal. To have an installer that an almost-averge-joe can use instead of a modified/custom built OpenSC that gets distributed by some other means. IMHO an installer caters to end-users segment (if the total audience of OpenSC would be end-users, integrators and developers) Feel free to modify the wiki page with ideas, corrections, proposals etc. [1] http://www.opensc-project.org/opensc/wiki/WindowsInstaller -- Martin Paljak http://martin.paljak.pri.ee +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
