I've thought long and hard about this reply. Indeed, this is the third attempt at replying, including one long and detailed description of the packaging tools and methods used by the project I mentioned above, which I then consigned to the bitbucket.

There are three problems with this idea:

1. AFAIK, MSIs weren't even a twinkle in MS' eye at the point in history when the project memtioned was evolving. Though I am reliably informed (but I deny it if asked in a court of law), that the product we were using was the inspiration behind MS's MSI product.

   What I can say is that the product we used, worked using exactly the same philosophy as MSI.

   1. Take a 'clean' machine installed with your basic target audience OS image.
   2. Perform a 'scan' of that machine recording everything.

      Directories, files and their ACLs. Registry entries and their ACLs. User groups, individuals and their permissions. And everything else that can change!

   3. Install the software to be packaged.

      This can be done through any mechanisms available or appropriate. Manually; via an installer; by copying from another machine; or any combination of those or any other mechanism.

   4. Perform a second 'scan' as above.
   5. Perform an (intelligent) 'diff' of the two scans.
   6. Review the diffs and exclude anything resulting from the process of installation, rather than the installation itself.
   7. Use the diff to generate
      • (compressed) archives (zips or other) of the new and or changed files.
      • Scripts to perform the installation.
      • Scripts to detect problems.
      • Scripts to 'undo' the changes in event of error.
      • Scripts to uninstall.
   8. Many intermediate details omitted. Nobody has heard of Novadigm Enterprise Desktop Manager, but this is almost exactly the way MSI works.
2. I do not have a spare machine on which to carry out this process.
3. Do you really want someone who has fundamental issues with the basic premise of your project as a team member?

   Especially one who is known for having viewpoints that are 'at odds' with the mainstream of opinion--the definition of 'mainstream' is somewhat fuzzy here--and for defending those viewpoints vociferously.

   I've said it before, and I'll say it again. On a commercial project, he who pays the piper, calls the tune.

   On a volunteer project, I expect my opinions to rate equal consideration with those of the other team members.

   Further more, I do not expect them to be 'shouted down' because they eminate from a 'luser' (read: non-unix user), or because they are couched in "Evil empire terminology".

   I think your project is a perfectly valid one--if you restrict your target audience to *nix-based developers who want a shallow learning curve option to building and testing their *nix-developed packages, in a Win32 environment.

   I do not believe that your project could ever be a replacement for, nor even a serious competitor to, ActiveState Perl for the vast majority of AS perl users. Much less, the serious Win32/Perl developer.

I agree that the AS PPM automated build process is flawed. Whilst I understand the motivation for their 'PPMs must be binary compatible with the latest major release' stance, the reality is that it is simply short sighted in the extreme. (Almost?) Every xxx.0 build (of anything) in history has been fundamentally flawed, and setting your waypoints as every xxxx.0 build is tragically stupid.

I once described the problems with the AS automated PPM builds as a "process problem", and the solution was to fix the process. That description was roundly poo-poo'd at the time, but I still belive that to be the case.