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
|
Re: Perl-based Installshield clone
by Fengor (Pilgrim) on Jul 12, 2001 at 13:42 UTC
|
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" | [reply] |
|
|
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
| [reply] |
|
|
| [reply] |
Re: Perl-based Installshield clone
by Abigail (Deacon) on Jul 12, 2001 at 16:04 UTC
|
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 | [reply]
[d/l] |
|
|
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
| [reply]
[d/l]
[select] |
|
|
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
| [reply]
[d/l]
[select] |
|
|
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".
| [reply]
[d/l]
[select] |
Re: Perl-based Installshield clone
by DrZaius (Monk) on Jul 12, 2001 at 19:48 UTC
|
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. | [reply] |
Re (tilly) 1: Perl-based Installshield clone
by tilly (Archbishop) on Jul 12, 2001 at 15:57 UTC
|
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". | [reply] |
|
|
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
| [reply] |
|
|
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...
| [reply] |
|
|
|
|
