Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Amiga Software News => Topic started by: GadgetMaster on June 01, 2002, 09:01:55 PM
-
"Negotiations are under way to integrate the InstallerNG into the new AmigaOS 4"
see:
InstallerNG Webpage (http://installerng.light-speed.de/)
-
This is good. InstallerNG always seemed to be a nice
package, and reading the user manual on the web page,
that impression is strengthened. But I was always a little
weary of installing something that crucial when the
first thing you see in the manual is:
"THIS IS A PUBLIC BETA VERSION
THUS THERE MAY BE MANY BUGS AND MISBEHAVIOURS AND MISSING FUNCTIONALITY.
USAGE IS YOUR OWN RISK."
Brrr.... (even though this is a standard disclaimer, It
still makes me shiver. It's the install tool we're meddling with
here...)
But hopefully that will change! If this is chosen as a
"standard" in AOS4, then they will of course make sure it is
stable and fits into the system. Thumbs up!
.
SlimJim
-
InstallerNG is not fully compatible with the official Installer - it seems to report errors on perfectly valid code, such as the "(confirm)" option, depending on the values passed or not passed.
I should point out that I have never, ever, ever used InstallerNG, and the above is based on people trying to use my scripts with it, rather than with Installer. Does ING support the new functions of Installer v44? Are there actually any advantages at all of using ING rather than the official one? Why replace a working program with a clone of it?
Chris
-
Why replace a working program with a clone of it?
Could it be that the V44 is still hanging in the
Amithlon-3.5-3.9-battle between AInc and H&P ?
-
Doh! Score a point off OS4. Installer NG is terrible!
-
Hmm.. Is that the same one you get with AIAB ? If so, it needs work, but looks promising..
-
In all fairness InstallerNG is a very good bit of software. It creates
proper uninstall scripts, allows you to move both back and foreward
through scripts, lets you skip over errors in the scripts etc.
Unfortunately it suffers from InternetExplorer syndrome.
The original commodore installer didn't stick to the script language
as documented - it works very well with buggy or broken code.
InstallerNG was written without the benefit of the original installer
source code, so it can only implement the documented language plus any
"quirks" the author has managed to find on his own. It therefore fails
on some scripts which work under the old installer despite containing
errors.
Hopefully hyperion will have passed on the original code to the ING
coder so such problems can be minimised.
-
there is a new function in ING:
LAZYCOMPILE: if set, then the InstallerNG is as lazy as the C= installer is. that means, InstallerNG skips its semantic check procedures to be more compatible
that means that ING is able to run the buggy code like Installer 44 without problem now
-
I don't like to slag off someone else's hard work, but I've found
Installer to be pretty poor. Even in "compatible" mode I had
problems.
Hopefully it will have improved by the time it is in OS 4. It may be
wise to include an older version as a back-up.
-
Well, if ING is going into AOS4, there is no reason the
whole installer code from at least OS3.1 couldn't be included for
backwards compatability in the worst case (if there aren't legal
squabbles over OS3.5/3.9 code, those could be implemented as well)
That should at least work nicely for the bulk of old, badly written scripts.
.
SlimJim
-
It creates proper uninstall scripts
Really? So if I install two apps, A and B, in this order, and they both want to install the same library (which will naturally only be installed by A, since it already exists when installing B), then will the library be removed if A is uninstalled? Or will it be removed only after both A and B are uninstalled, as it should?
-
Feature-wise, InstallerNG is interesting.
But I can't say much good of a program that has kept crashing my system whatever the version I tried...
-
@msundman:
Good point. What I should have said is:
Creates an uninstall script.
That said, it shouldn't be too hard to implement - just store a list
of all libs etc. installed with a count of the number of apps which
appear to use them. If it's greater than 1 at uninstall, leave them.
If it's 1 at uninstall, remove them.
-
it shouldn't be too hard to implement - just store a list of all libs etc. installed with a count of the number of apps which appear to use them. If it's greater than 1 at uninstall, leave them. If it's 1 at uninstall, remove them.
I bet this is how M$ would do it, but it's not that simple. It also has to support uninstall cleanups because of inconsistencies made by users who manually "uninstall" programs. It should probably also store what versions of a particular library some application needs and wants. It should also support upgrading existing applications. [...]
-
Yeah, but the whole point is that you don't have to do that sort of
thing by hand...
-
Yeah, but the whole point is that you don't have to do that sort of thing by hand...
I assume you mean manually "uninstalling" programs. (You sound very much like a M$ employee.)
If something can be screwed up some way then there will always be someone that manages to do it. You can never rely on the users to behave. Programs must always take worst-case scenarios into account!
-
True enough.
-
I bet this is how M$ would do it, but it's not that simple. It also has to support uninstall cleanups because of inconsistencies made by users who manually "uninstall" programs. It should probably also store what versions of a particular library some application needs and wants. It should also support upgrading existing applications.
That is the way MS do it... or at least the way InstallShield handles things. It tends to screw up if you reinstall without first deinstalling however. Oh, and InstallShield doesn't seem to care about DLL versions. On the Amiga you don't need to worry about these things, because libraries are always API compatible with older versions, and Installer does the version checking for you.
Chris
-
InstallerNG Homepage (http://installerng.light-speed.de)
savage@light-speed.de
i was working on the InstallerNG for a long time. it started off as a compiler project, thus i emphasised a clean language specification and a good compiler kernel. it occured pretty early to me that the C= Installers language, as well as its implementation is bretty bad. by doing a better job i had to accept the fact that really bad scripts won't work anymore. but those scripts can be fixed within minutes. compatibility is a big issue, i agree, but i prefer to have a good compiler and bug-fix scripts rather than having a lousy compiler that swallows everything. (btw, its harder to make mistakes if the compiler is picky. accept that!)
some of you complain about the iNG crashing. so send me a bug-report then, and i can try to fix it. i rely on you guys here, since the iNG works on my machine, and many many others do not have a single problem.
future work... well, send me bug-reports. send me suggestions. send me scripts if you think they are right. you want the iNG to be a useful tool? me too... then support it, and don't just complain how $#@! the iNG is.