Re^5: Getting Fed Up with ActiveState

[BrowserUk]

... freeing them from the shackles ...

You have no concept of how corporates work. They love shackles. They invent shackles were there are none.

Do a supersearch of this place and look for all the posts that say variations on the theme of "I'm not allowed to install any modules" or "getting approval for the installation of a new module is a long and tiresome process".

If an IT department is going to distribute a Perl-based application to a couple of hundred user machines, the last thing they want to do is distribute a compiler, and mock-unix development platform to every machine also. Nor do they want to have to visit each machine individually and answer the same bunch of questions over and over in order to perform the installation.

And they sure as hell don't want to enable the user to pull random chunks of sourcecode from an open server (CPAN) and compile them locally.

They are just packaged installers.

Your concept of an 'installer' is bad also. When a corporate uses an MSI installation, it gets much more than just a bunch of files slapped onto the disk somewhere and then replicated to another part of disk leaving all the junk lying around.

A few of the benefits of using an MSI installation:

• Restores original computer state upon installation failure: Windows Installer keeps track of all changes made to the system during the application installation process. If the installation fails, Windows Installer can restore, or roll back, the system to its initial state.
• Helps prevent certain forms of inter-application conflicts: Windows Installer enforces installation rules that help to prevent conflicts with shared resources between existing applications. Such conflicts can be caused when an install operation makes updates to a dynamic link library (.dll) shared by an existing application, or when an operation deletes a dynamic link library shared by another application.
• Reliably removes existing programs: Windows Installer can reliably uninstall any program it previously installed. It removes all the associated registry entries and application files, except for those shared by other installed software. You can uninstall an application at any time after a successful installation. (Removal should not be confused with rollback, which restores a computer to its initial state when an installation failure has occurred.)
• Diagnoses and repairs corrupted applications: An application can query Windows Installer to determine whether an installed application has missing or corrupted files. If any are detected, Windows Installer repairs the application by recopying only those files found to be missing or corrupted.
• Supports on-demand installation of application features: Windows Installer can be instructed to initially install a minimal subset of an application. Later, additional components can be automatically installed the first time the user accesses features that require those components. This is known as advertising. For example, Windows Installer could install Microsoft Word with a minimal set of features. The first time the user tried to access a mail merge function (not included with the original installation), Windows Installer would automatically install the mail merge component. Similarly, Windows Installer can also purge components that go unused in an application. For example, Windows Installer could be configured to remove the mail merge component if it goes unused for 60 days.
• Supports unattended application installation: Installation packages can be configured to require no installation process interaction from the user. During the installation process, Windows Installer can query the computer for desktop attributes, including determining whether any applications were previously installed by Windows Installer.

And this doesn't even to begin to list all the security aspects. Like installing Perl on a machine such that only users who are members of a particular group can use it, in hot-desk environments where any employee can sit down at any machine and log on, but each user has different priviledges. Using an MSI, installing an application so that an non-authorised user won't even be able to see it is trivial.

Remote installs. I built a system for the remote installation and maintanence of application software on 40,000 desktops and portables located in dozens of separate sites distributed across an entire country. Any employee could walk into any site, sit at any desk and log on and his user profile (down to his choice of fonts and desktop colours--which is a legal requirement for visually impaired employees) was loaded onto the machine automatically. And if he attempted to use an application that had never been installed on that particular machine before, it was installed for him as he waited. When he logged off and the next user sat down to use it, it was a legal requirement that the next user would never be able to see anything that the previous user had been doing. There are 23 divisions within the company (actually a government department), and it is a legal requirement that all their work must be kept separate.

Using MSIs in this type of environment is a delight, because it knows and understands about the security setup; roaming profiles; domain based networking; and all the other bits and pieces that are need to make this work.

Trying to set this up with a 'installer', based around an emulation of an OS that has none of these concepts, would simply be impossible.

[xdg]

You have no concept of how corporates work. They love shackles.

That must be why they prefer Java to Perl. :-)

Trust me -- I understand corporates quite well. But one can always dream.

... variations on the theme of "I'm not allowed to install any modules" ...

Non-sequitur. If they're not allowed to install modules, it's all irrelevant. If they are allowed to install modules, then they might wish to use PPMs that rely upon core modules written since 2003. Moreover, even those using the latest release of ActiveState -- with up-to-date core modules -- can't get AS-built PPM's unless those PPM's build cleanly against the first 58x release. They have the dependencies -- just the build farm doesn't.

Side note -- one way AS could probably resolve this conundrum is to keep a separate build-farm and PPM repository for the first 58x release and the latest 58x release. Or just keep a separate build-farm and repository for each 58x minor release.

Your concept of an 'installer' is bad also. When a corporate uses an MSI installation...

That's a known issue. If you look at the roadmap for Vanilla Perl, switching to an MSI installer has been on the list for a while.

I built a system...

I'm very impressed. Are you at all interested in applying your experience to help instead of just pointing out shortcomings? I'm serious here -- not trying to be snide -- you clearly have thought a lot about this and have tremendous practical experience with MSI's and I freely admit I don't. I know we'll need experts to get it right.

[BrowserUk]

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.