[haiku-development] Re: software organization/installation
- From: Rick Hansen <in_rapture@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 18 Feb 2009 08:14:44 -0800 (PST)
--- Michael Kanis <mkanis@xxxxxx> wrote:
> Am Dienstag, den 17.02.2009, 10:28 +0100 schrieb
> Christian Packmann:
>
> > No. He uses one of the clicky-clicky installer
> generation apps, either commercial or freeware. I
> haven't used any so far, but the modern installer
> generator seems to be pretty good from what I've
> read.
> I think you didn't get my point. It doesn't matter,
> who wrote the
> installer. 3rd party installers are not "good", they
> are a hacky
> workaround for a problem, the OS should provide a
> solution for and does
> not.
And the package management/repo systems in Unix are a
hacky work around to the Unix philosophy of an OS
being a huge organic blob of incestuous libraries and
and apps. Both have their pluses and minuses. I do
agree that the OS (actually, maybe not the OS so much
as the development tools for the OS) should provide a
standard "easy" means of building GUI or batched
install executables/packages/bundles or whatever.
> Also, even if there is a package manager or some
> other solution provided
> by the OS, you can use crappy installers for YOUR
> software. Nobody
> forces you to do anything for the software you
> write. But this is not an
> excuse for not providing this solution.
>
Depends on the system. In the Linux world, where there
is no real OS, as everyone defines it elsewhere, you
can't and have it work correctly. You end up relying
on something that you assumed was in the "OS"
distribution. Loki games are one example (at least the
couple I had, I chucked them when they got to be too
much of a pain since the Windows versions still work
fine). The installers run fine but they are still
relying on some old library that doesn't exist in the
repos any more and you have to go get the source and
build it yourself. So, unless you are bundling
everything from glibc on up on Linux, a bundled
install just won't work. For Haiku, the situation
currently doesn't seem nearly as bad. But, my fear is,
if you end up with run away dependency problems, it
could end up that way over time.
> I don't think, there is currently the one solution
> to this problem. But
> package managers, as on most Linux distributions and
> other UNIX-ish
> systems are one attempt, self-contained Bundles as
> on Mac OS X are
> another one. Typical standalone installers as most
> software on Windows
> uses are the worst attempt man ever made to try to
> solve the problem.
> Even if many Windows users get used to them, this
> makes them neither
> user nor developer friendly compared to the
> alternatives.
>
I completely disagree. All methods are very user
friendly and suck, just in different ways. For
starters, when I run a Windows style install that I
have on a CD or from an internet download, I get the
same thing every time. I know that my copy of MS
Office (or whatever) is not going to change on me each
time I install it no matter how much time passes. I
also know that, in general, when I install it on the
next version of Windows I am not going to get some
cryptic error like "Missing dependency
libIwasDepricated". As a user, I really don't care how
hackey the install method technically is if it feels
clean and works consistently AND gives me the version
with the features I am expecting (nothing funner than
getting a version of software you HATE just because
the distro decided that's what they were gonna give
you, i.e. KDE4 and friends in Ubuntu). On the other
hand, I will give you that going to a screen, browsing
through a list of applications, finding one you like
and hitting install (assuming that's the version you
wanted) can be pretty darn easy and user friendly.
Anyway, if Haiku as a system implements most heavily
used library functionality in the OS, then we
shouldn't see that big of a need for many global
libraries and hopefully we can have it both ways. You
can have your repositories, and I can have my stand
alone install packages.
Other related posts:
