Perl-based Installshield clone

[Jouke]

While crazyinsomniac, BrentDax and me were discussing The Perl Compiler I -again- came up with the idea of writing an Installshield clone. I had thought about that before, but didn't have the nerve to start such a project, because it involves a lot. Let me explain what I think this should do:

InstallShield is a setup-tool to let you -as developer- create a setup-wizard for your windows-based programs. It copies your files to the directory a user specifies, modifies configfiles, adds programgroups and desktopicons and more. The user gets a user-friendly setup for your program.

There are several clones available for Installshield, like Inno Setup This is really a great product: free, open source (though not GPL), what else could you possibly wish for? Well, I wished it ran on Linux. And it doesn't, because it's written in Delphi, and is of course written specifically for Windows because it has to be able to modify *cough* registry-entries and desktop icons...

So I went and searched for a similar product for Linux. And I found Loki's Setup which looks and sounds really great. However I could not get it to work on my machine. This may of course be my own fault, but I was mainly frustrated that such a tool does not have it's own "easy installer", but needed to be installed in the conventional way, using configure and make.

So I decided I wanted to build my own version of this. In Perl of course. It would be quite complementary to The Perl Compiler. It would be mainly focussed on the Linux platform, not closing any doors for Win32 or Solaris (or other unix flavours). And aimed at GUI applications that are distributed in binary form (so it does not need to compile it first...)

I'm going to setup a Sourceforge project for this, and wondered if anyone has suggestions for the project. If anyone would like to co-develop this, please let me know.

UPDATE: I mentioned distributed in binary form, but I actually meant to say programs that don't have to be compiled first. So if you built a Perl/Tk application, that would suffice too

Jouke Visser, Perl 'Adept'
Using Perl to help the disabled: pVoice and pStory

[Fengor]

Well an installer would be nice to have of course, but there are problems associateed with it:

A good installer has to be able to be run on any system with perl on it and how are u going to embrace all the different soft- (i.e. win, linux, mac, bsd, etc) and hardware (x86, PPC, S390, ...) architectures out there?
I mean even if u concentrate on linux u will have a problem: will it run on redhat? will it run on SuSE? and whats with debian or rocklinux?

So to put it shortly: In my oppinion it's definetly a nice idea but not the time for it yet. We first need a set of standards which everyone follows. The not-existing of these standards is as i see it the only reason why no general automated installers exist in linux. The only automated installers we have are distribution specific like rpm, apt-get, yast etc.


--
"WHAT CAN THE HARVEST HOPE FOR IF NOT THE CARE OF THE REAPER MAN"
-- Terry Pratchett, "Reaper Man"

[Jouke]

I don't quite get your problem...

I don't see what the OS, or hardware has to do with the installation of compiled binaries on a system where you only have to say where to put the files and to add icons to programgroups and desktops.

Sure, I have to cope with different windowmanagers like KDE, Gnome and Win32, but that's something I can live with.

If you know what Installshield does, you know that is's just a shell around a 'copy the files to the right directory'...well, OK, a bit more than that, but basically it has nothing to do with the OS and not at all with hardware...

Jouke Visser, Perl 'Adept'
Using Perl to help the disabled: pVoice and pStory

[Fengor]

Well the right places for the files varies from system to system. u may wanit it to put in /usr/bin /bin /usr/local/bin /some/place/else same goes for libraries and all other stuff. Each distribution handles this sort different

--
"WHAT CAN THE HARVEST HOPE FOR IF NOT THE CARE OF THE REAPER MAN"
-- Terry Pratchett, "Reaper Man"

[Abigail]

If all this "install shield" is going to do is copying files to directories, then what is this shield going to do that isn't already done by

    perl Makefile.PL
    make
    make test
    make install

Of course, the ExtUtils do much more, like creating documentation and such.

-- Abigail

[Jouke]

It's not going to do the part that is being done by

    perl Makefile.PL
    make
    make test

It's merely going to do the make install and add the possibility to modify configurationfiles your application needs, create icons, etcetera through a userfriendly interface, and I think you agree with me that less-technical users will not really like the make-like process, especially when it can't find libraries (ones you either installed or not) just to build the application...

Jouke Visser, Perl 'Adept'
Using Perl to help the disabled: pVoice and pStory

[Abigail]

There are various modules out there that require configuration files to be made/updated. Net::FTP and CPAN spring into mind. That seems to work quite well from the make process (although sometimes it's deferred to first usuage). As for the oh so scary make process (all you need to do is copy and paste the instructions from the README file, but I guess you assume some people are too afraid to do so), there's the CPAN module which is a wrapper around this scary make process. It will even take care of dependencies for you!

-- Abigail

[Anonymous Monk]

But the make *should* configure your app already. make install should only copy the already configured app into the appropriate dirs and update the config-files of *other* apps to represent "yeah, package xyz is (over) there".

[DrZaius]

If you are going to do something like this, it should be in dispatch style.

When I install gui software, I want a small installer. I run it and it realizes I'm running distro x on architecture y, which uses rpms. Therefore, it pulls the rpms off of a web site, does dependency checking and so forth. My software is installed and I'm happy.

It should be able to work on and linux, *bsd, macos*, win*. Yes, I said win*, new versions of windows use MSI packages.

My requirements in an installer for opensource (or closed, I suppose) would be the following:

• Cross platform/architecture
• Web enabled (only download the installer first)
• Only knows how to detect the operating system/platform and how to download the correct files.
Every platform is going to use packaging systems and locations for files. I wouldn't try to fight that but keep packages for all these different systems around.

[tilly]

What real purpose does something like installshield really serve?

I guess I never liked the original, and I prefer the option of installing things with command-line tools. (Like apt.) So if you do build this, my one request is that it should have a mode for people who don't want to see any "pretty pictures".

[Jouke]

The idea is to use the "pretty pictures" That's the base of it. It's not going to replace RPM, APT or whatever. People who are used to it and happy with it would never want to use an installation wizard.

However, I've heard many people ask for a "pretty pictures" installation on Linux. Most of these people are coming from a win32 environment and want the same kind of interface.

I admit being one of them....

Jouke Visser, Perl 'Adept'
Using Perl to help the disabled: pVoice and pStory

[tilly]

But do you envision software being shipped at some point expecting to be installed with your install package?

Do you expect companies who do that to go through the effort of also providing .rpm and .deb format installs that they have tested? Realistically I don't think that will happen. It would be great if it did, but I try to be realistic about these things and I just don't see them doing that duplication of work just because some tech thinks other techs would like it.

That is my concern. Personally if I have a choice, I will not use software on Linux that requires a pretty GUI installation. It is something that I hated about Windows, and with apt and friends I have no shortage of software that I like which doesn't force me to sit like a monkey and click buttons. (Or force me to do undue work trying to script an installation that was clearly designed for marketing and not for a tech.)

This may be unusual, but that is how I am. As Unix as Literature points out, people who are attracted to Unix often actively prefer working with text to working with a gui. Of course there are many people in the Linux world today who are there for other reasons and don't share this underlying bias, but we still exist.

For these reasons and more, the way that I would like to see this itch scratched is in defining hooks in the .rpm or .deb format which allow someone to distribute software in an accepted format which will, if installed with an optional front end, give people a nice graphical installation. That is, instead of creating a portable tool in which people define their install-shield like install once and say, "OK, that is it for all of our platforms" (leaving me a second class citizen) I would like to see the GUI install not come into conflict with existing and accepted methods of installing and managing software.

And, of course, such a front end to rpm or apt could easily have some default GUI that it uses for the inevitable packages that have no GUI hooks installed. And you would probably join me in avoiding that front end when you are trying to install a new machine with about a thousand packages...