Hello,

On Apr 1, 2011, at 20:02 , Martin Paljak wrote:
> Windows7 build machine is currently offline but will be brought back online 
> for next week and onwards (have a look at how upgrading to Windows SP1 went: 
> http://martinpaljak.net/windowswtf.png )
Done, a fresh VM is up and running and the build slave installation procedure 
tested once again - easily repeatable. I wish I had not closed the wiki window 
with the un-saved tutorial, which I now need to create again... later.

> Some comments about the MSI that need to be dealt with before release, IMHO:
> * License in installer: CPL -> LGPLv2. Maybe some nice theming for the 
> installer, a la OS X background.
Done, LGPL license converted to RTF. Maybe a different path/tool could be used, 
the license does not look nice in current formatting. Also, additional 
information could be provided before/after the LGPL text ("If you brick your 
chip, it is not our fault" style legalese)

> * Components panel either removed or fixed (currently there seems to be 
> "something" but there are empty strings for the main and subcomponent)
Done, installable features are a bit more laid out and described. Minidriver 
should be disabled by default, core not removable and tools+profiles/PKCS#11 
optional.

> * Installation location. The distributed DLL-s should IMO go to Windows 
> folder. The three files that should go to system32 or equivalent are:
>  * opensc.dll - does not pollute nor should it conflict with other software.
>  * opensc-pkcs11.dll - predictable/known path for the PKCS#11 module.
>  * opensc-cardmod.dll - most other minidrivers install to system32 as well.
>  * none of them is a "program file" but relate to system services to some 
> extent. Also I don't know any practical reasons why it should be in the 
> installation folder in program files, other than "it would be nice" and "it 
> may contribute to dll hell" (compare to GUID vs other unique id formatting)
I still think this is the right thing to do for a *MSI*. A pure PKCS#11 
"portable edition" (AKA one that can be easily moved and one that does not 
require any privileges to install) would make sense but that should be tested 
with some portable apps.
Maybe some more flexible method in the MSI would be even better, but that would 
require a patch or some executable ideas.


> * Directory layout. Windows is not Unix. The directory layout is hand picked 
> by the wix script anyway, so I'd suggest something following in C:\Program 
> Files\OpenSC
>   \opensc.conf
>   \tools\opensc-explorer.exe
>   \tools\...
>   \profiles\oberthur.profile
>   \profiles\...
Done. File Id-s in OpenSC.wxs also changed to be more like actual file names 
(except where limited by WiX ...)

> * Start menu entries, if any. I'd suggest "OpenSC tools folder" and a link to 
> opensc-project.org documentation. Or only a link to the documentation. 
Executing opensc-explorer.exe is no good, if you don't have a card in the 
reader there's just a flashing windows disappearing. And do we *really* want 
people to get the visual understanding of OpenSC as opensc-explorer interface? 
No crypto, nothing. I doubt it.
If somebody knows how to instruct WiX to open a cmd.exe in the tools folder of 
OpenSC, please let me know. IMHO that would make more sense.

> * File versioning. Current .rc uses the libtool related version in the file 
> versioning which is not optimal. It has to my knowledge no relation to the 
> libtool interface versioning. Versions from OpenSC version and SVN revision 
> could be used instead. 0.12.1.5247 for r5427 in the 0.12.1 build cycle
Still needs work. I hope this will not interfere with mingw build.

> * Testing for conditional installability based on architecture and OS release 
> (will matter for minidriver installs, XP with minidriver 5 is not OK for some 
> operations and multiple PINs.)
MSI should support creating a unified installer with both 32 and 64 bit 
components. 64 bits only matters for 64 bit applications (none in PKCS#11 field 
that I know) and for a 64bit minidriver (which is highly experimental still). I 
thus think it is OK for now to leave it as it is - a x64 msi available but not 
really advertised. Side-by-side installation would be another tricky question.

Things to consider/fix: zlib, upgrades (requires some WiX magic, currently it 
is only possible to install the MSI and then uninstall OpenSC via control panel)


Feedback ?
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to