Christopher Browne <[EMAIL PROTECTED]> writes:
> It seems to me to make sense to use the appropriate dependancy management
> system for differing Linux and BSD systems. If we build our own, all
> we accomplish is to force an extra packaging system that will conflict
> with the "native" one (e.g. - RPM/dpkg).
You're missing some fairly important issues here. We have talked
about the "installer problem" at some length in the course of trying
to make gnucash ready to sell. Haven't solved it, but we need to.
Of course you want to have RPMs for rhat, suse, etc and .debs for
Debian. The very simplest case of installation is just to use the
system tools, install one package, and be done with it. This is the
least invasive kind of install and the one that you want to do
whenever possible.
That's assuming that users have an up-to-date install of everything we
need, including the Gnome tools, on one of the major distributions.
To do this right, you have to detect that you are running on a debian
(rhat, etc) system and that the installed dependency libraries are all
up-to-date enough before going ahead and trying the install. You
might have a fallback to try to upgrade installed versions of gnome,
etc from packages on the distribution medium, given that the user is
willing to do that.
But what if you are installing on an old Slackware system that has
been upgraded by hand a million times? What if it's a Red Hat system
that doesn't have Gnome installed and is too far back in the stone
ages to allow gnome to be installed without upgrading a bunch of other
packages? I think most of the Linux installs out there are probably
two years or less old, but there are a significant number that are
older and cruftier than we want to imagine.
In the end, you're going to need something almost like configure to
make sure that the libraries you depend on are actually installed and
you can find them (it's not good enough to trust that the package
manager says they are; what if the user moved/renamed things?)
The "sledgehammer" approach is to ship a statically-linked binary.
That's really a last resort.
And what if the user doing the install isn't root and can't even write
in /usr/local? There's no reason someone on a big multiuser Linux
system shouldn't be able to install gnucash from the CD (assuming they
have CD read access). There needs to be some way to re-root the
install at install time so that you can put gnucash under an arbitrary
directory without re-configuring and re-building. Of course that
means you can't use rpm or deb for that kind of install; need a
straight tar file.
I don't really have a clear idea how to address all these problems,
but I think I have thought about it enough to say that a really good
installer that cooperates with the package system on the install
machine would be great.
Bill Gribble
