But that's not really my point, and I know I'm not really addressing
yours about packaging. So far, most packages off of Linux (i.e. FreeBSD)
are generated by voulenteers. If you can get a voulenteer to compile and
build a package on a certain platform, great. The same would need to hold
true with an installer. I'm sure AbiSource doesn't have the budget to get
exotic UNIX machines so they can build installer binaries.
The ironic thing is you would really have to make a package of the
installer for whatever platforms you wanted binaries on. I can envision a
statically linked excecutable within a tgz, but if you can compile an
installer wouldn't it just be better to build a native package.
If the point is to detect the right libraries, why not make it a
non-graphical shell script? That way it would have ultimate portability,
it would be simple and slim, and ideally you could use it as the make
install for a source tree (on many platforms that don't use rpm/deb
AbiSource can't make binaries of the installer anyway becuase they don't
have access to XYZ platform, and it is hard to find people who do have
administrator access to a IRIX or HP/UX or Ultrix system. I think the
soulution for platforms like that would be to just build the app from
source and avoid package management entirely. A good install script would
be useful and simple).
Motif would not be necessary for X11 though, athena is bundled on all X11
systems that I know of and is even freeer than GTK :)
even better - Xlib!!!
On Sun, 18 Jul 1999, Drazen Kacar wrote:
> Aaron Lehmann wrote:
>
> > > > 2. I have basically the same question about how the installer was
> > > > created.
> > >
> > > The installer was hand-written in C. It should be considered a work
> > > in progress, and unless it gets completed, the project may eventually
> > > end up switching to a plain old InstallShield setup program. The
> > > intent of the current installer was to make it XP as well, porting it
> > > to GTK and BeOS later. We have not gotten that far yet. Even the
> > > Win32 version needs some work right now.
> >
> > In my opinion, UNIX doesn't need an installer and it would be more likely
> > to lengthen the install process and confuse people. UNIX already has
> > standard mechanisms for dealing with packages (deb,rpm,slp) and it it what
> > people are most used to and best integrates with their existing
> > installation (dependencies...).
>
> That's kind of complicated, because Linux is not the only Unix out there.
> I'll take Solaris as an example, mainly because that's the Unix version
> I know the best. It's probably applicable (to some degree, at least) to
> other systems.
>
> Solaris (as in "Solaris[tm] operating environment") normally uses Sun's
> packaging system. But some people use deb or rpm to install and manage
> additional software packages. This means that you can't know which
> packaging system manages GTK libraries and you can't know where they
> are located. Solaris doesn't have anything like `ldconfig' utility,
> which complicates things considerably. If the library is not located in
> /usr/lib, run time linker will find it if the location was specified
> with -R flag during the linking phase of the executable program or
> LD_LIBRARY_PATH points to the appropriate directory at run time.
>
> -R can't be used since you don't know the location of GTK library on a
> target system. LD_LIBRARY_PATH will work, but it's an overkill. If
> every program required it, that method would become unmanageable.
> Most (all?) of commercial programs solve this problem by shipping their
> own versions of every external utility or library that they need.
> So I'm likely to get yet another version of Perl if the program requires
> it, yet another version of Apache if it wants to serve something via
> web interface and even yet another version of Java, although I have
> the better one installed (and managed by Sun's packaging system)
> in /usr/java. My immediate reaction to this kind of programs is
> "What a bunch of losers." But, doing it right can be quite tricky.
>
> AbiWord should bring GTK library with it, but it should be installed
> only if it doesn't exist on a system. And the installer should try
> to recognize as many packaging systems as possible. If there's more
> than one, it should ask which packaging system should be used to
> manage AbiWord. Then it should ask if an administrator wants it to
> perform CDE integration (I absolutely hate programs which do this
> without asking first). Then there might be other ways which are used
> to make the application appear in a menu (or whatever) in other
> desktop environments or window managers.
>
> All this is far from simple and easy and some kind of installer
> program is probably needed. Now, most of commercial Unix versions
> have Motif bundled and that's probably the only graphics environment
> on which one can count, before the installation is complete. Fortunately,
> dtksh will exist on these systems, so the installer can be written
> as a shell script. It's somewhat perverse to use Motif GUI to install
> GTK applications, but I like that kind of perversions. :-)
>
> Then there is a network installation. In this scenario you have one
> server which has all read-only parts of applications which are served
> via NFS to the workstations where people actually use them.
> This is fairly important. As an illustartion, I have Sun's C, C++, Fortran
> (77 and 90), Motif GUI builder and some other things. All in all,
> those applications need about 540M of disk space. There's no way to
> install them separately on each host where they should be available,
> because there is no disk space, so they have to reside on NFS server.
> But then, some programs need something in /etc (for example) on the
> host on which they are running, so you'll have to have a separate
> package for that. Again, installer program would be quite handy.
>
> --
> .-. .-. Life is a sexually transmitted disease.
> (_ \ / _)
> | dave@srce.hr
> | dave@fly.cc.fer.hr
>