from what i have read about install issues, and with the new install scripts using python but not much documentation being around, would a bounty for a reaction based installation utility be worthwhile?
something where devs can use a GUI front-end to just say these are the files, this is where to put them, it then puts it all in one archive, and when executed runs installer.
it would always use unarc, so protection bits would not be lost, it would always check if files exist already and check file versions are correct before installing, and so on.
you tell me, would this be useful to anyone making or running applications? would there be certain extras that would have to be included to make it worthwhile?
Hans has come up with similar issues, although i was thinking not everyone needs to become experts in writing installer scripts if a easy to use program can do it for you (and allow you to edit the script if needed anyway)
It should be possible to analyze the binary to find *.library *.mcc *.font *.ttf to generate the dependencies. Package directory tree can be generated, and install script.
The installer should be so intelligent that if HUNK files is found it does not replace ELF files.
It’s nice to create a new package management system is nice but does not solve problems whit old programs.
I believe we really are going to solve this problem we need the help of Hyperion.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
derfs wrote: from what i have read about install issues, and with the new install scripts using python but not much documentation being around, would a bounty for a reaction based installation utility be worthwhile?
something where devs can use a GUI front-end to just say these are the files, this is where to put them, it then puts it all in one archive, and when executed runs installer.
it would always use unarc, so protection bits would not be lost, it would always check if files exist already and check file versions are correct before installing, and so on.
you tell me, would this be useful to anyone making or running applications? would there be certain extras that would have to be included to make it worthwhile?
what does everyone think?
Would it not be possible to adapt something like Cranu , to generate an install script when creating an archive, as an option if course. So maybe Peter Gordon is the guy to speak to.
Similar topic has come up on OS4Coding.net, I haven't mentioned this yet, but these should be the basic requirements of an installer or rather the python Installation Utility.
1) Version checking when copying files. MANDATORY 2) No bollocks Basic, Advanced and Expert modes - not necessary if written correctly. 3) Checks AmiDock for presence of application icon and if not present adds icon into the main dock area. MANDATORY 4) Graphics. Customisable top header. MANDATORY 5) More graphics. In a lengthy installation it should be possible to display a selection of graphic banners at say 10%, 30%, 50%, 70%, 90% or whatever. Eg. feature list. OPTIONAL
Probably more points to be fair, but they are the most important.
IMHO better to start as small & simple as possible, then gradually improve it (at least partly based upon feedback - rather than some obtuse personal theory). Avoid big complex design that will be a nightmare to code, and too complicated for anyone to use (or at least which they would ignore half the features of).
Would also be a good idea to reuse as much existing work as possible, to avoid reinventing the wheel & making maintenance harder. Chris's suggestion of using our existing Installer makes sense to me.
ChrisH wrote: IMHO better to start as small & simple as possible, then gradually improve it (at least partly based upon feedback - rather than some obtuse personal theory). Avoid big complex design that will be a nightmare to code, and too complicated for anyone to use (or at least which they would ignore half the features of).
Would also be a good idea to reuse as much existing work as possible, to avoid reinventing the wheel & making maintenance harder. Chris's suggestion of using our existing Installer makes sense to me.
how about an "installer" for installer, where its a GUI program that you can give all the required files too, its creates an install script for installer, as well as creating a single achive to run it from.
IIRC installer already can check version numbers for files needed, so it checks which files you give it, and only copies it over if its newer.
this way, you dont have to learn python for the new installer for simple packages.
amiupdate can be used to keep things up to date once its installed.
how about an "installer" for installer, where its a GUI program that you can give all the required files too, its creates an install script for installer, as well as creating a single achive to run it from.
That's basically what I was suggesting.
Quote:
IIRC installer already can check version numbers for files needed, so it checks which files you give it, and only copies it over if its newer.
Yes, it does, if you use copylib. copylib only supports single files - but it is a breeze to do a foreach loop to copy more than one, I use this to copylib everything out of the libs dir in my NetSurf install script.
Once we have documentation for the new Python-based Installer, the Installer script generation wizard could be updated to output scripts for that too, as well as AmiUpdate AutoInstall scripts.
I'm going to be cheeky and suggest you could probably write this in Installer if you so desired
It should be possible to analyze the binary to find *.library *.mcc *.font *.ttf to generate the dependencies. Package directory tree can be generated, and install script.
What if my program checks if a library exists using OpenLibrary(), but doesn't actually need it? Such a dependency list should be used as a guide only. In fact, I recommend that people use Snoopy to get the dependencies so that they know what to include.
BTW, I used Advanced Installer to generate the GfxBench2D for Windows installer, and even there, making sure that the dependencies are included is the developer's responsisbility.
how about an "installer" for installer, where its a GUI program that you can give all the required files too, its creates an install script for installer, as well as creating a single achive to run it from.
That's basically what I was suggesting.
Ah, so you actually mean an installer generation utility, not yet another installer.
I'm all for such a utility, and I couldn't care less if it used Reaction or MUI. Having used Advanced Installer on Windows, I can say that having such a utility makes life so much easier than having to write the scripts manually.
I think that one of the reasons why so many developers don't create installers is because the task of learning yet another scripting language is rather daunting. This is particularly true if you've already spent so much time creating the app, and would love to share it ASAP.
The configuration page on the left shows all commands, which are very easy to learn.
We need UserC, UserLibs, UserPrefs drawers so not to mess with official SYS: partition.
Detect library version : if newer, copy old version to UserLibs then copy new to SYS: if older, check if there is already in UserLibs first, then copy to UserLibs.
Just in case a specific program requires a specific version to work. In this case installer should log similar libs file and FLAG the program that requires it.
This will keep a record of dependancies and find problem programs that can be reported and fixed.
Which is the better solution - Flag the file that requires specific version of a Lib or just copy a different version to UserLibs ?
MD5 logging of files and operations. Record each stage for documentation automatically. Templates Silent Install for multiple systems simultaneously
could having specific folder structure be useful ? eg all docs in subfolder Docs
EG recommended structure :
MyAppFolder -MyApp -Docs/MyAppDoc
Installer maps shortcut Program shortcut "MyApp" to MyAppFolder/MyApp Programs documentation "MyAppDoc" to MyAppFolder/Docs/MyAppDoc
So now shell or any program can execute program : "MyApp <options>"
or call ANY Programs documentation by executing : "TextReader MyAPPDoc"
A table keeping this information can be parsed to create or recreate HTML documentation with links to apps/tuts etc or even embed code,examples, version numbers, settings - anything !
If you follow structure guide your app will be detected, if you want to install app anyware - dont expect detection.
Ah, so you actually mean an installer generation utility, not yet another installer.
sorry, my fault for not being clear with the title.
As Chris said, if the generation utility supports it, then at first it can support the old installer, and then the newer one once the documentation comes out.
My main thoughts started with "How can this be made easier", and not so much "what can be added to it". A preview option where it runs installer but doesnt copy any files would help IMHO.
Would this be worthwhile to create a bounty?
With the other suggestion people have made, it is more for a installer "guidelines" list, or replacing the existing installer. the former needs to be done by Hyperion, and the latter just needs documentation as it already exists.
Ah, so you actually mean an installer generation utility, not yet another installer.
sorry, my fault for not being clear with the title.
No worries, it's clear now.
Quote:
As Chris said, if the generation utility supports it, then at first it can support the old installer, and then the newer one once the documentation comes out.
My main thoughts started with "How can this be made easier", and not so much "what can be added to it". A preview option where it runs installer but doesnt copy any files would help IMHO.
Would this be worthwhile to create a bounty?
Yes, it would be worthwhile. Make sure that the bounty explains why it will be beneficial to end users though (i.e., more programs/libs will have decent installers).
Hmmm... Just posted on this subject on AW as well... I had been thinking of writing an installer script generating utility in the past for OS3.x - maybe I'll revive this idea and get cracking on it, it would work fine for OS4 as well.
Developer time is precious in today's Amigaland so before somebody jumps on creating an installer generation utility, it would be nice to have a word from Hyperion as regards the future of the actual Installer. Are they planning to ditch the original, Lisp-based one in favour of the Python installer? Are they going to supply any documentation with the latter?
That's true, but given that the LISP-based installer is still current for OS4.1, a script creation utility would surely be worthwhile for some time at least, especially if it works on OS3 as well, as there are still plenty of packages being released for 3.x - more than for OS4, if the Aminet recent list is anything to go by...
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
