I've been quite disappointed by the process involved in updating the Enhancer Software from v1.1 to v1.3, especially since some of these issues were present since at least v1.1 :( .
With the Installer:
* Every time the installer runs into a minor problem (e.g. fails to create a file), the ENTIRE installation process stops, meaning I have to run it again, and laborously re-enter all my installation choices again :( . (a) Please add graceful error handling, rather than halting installation. (b) It would be great if it remembered/defaulted to my previous installation choices (at least for the main ones like the backup location, my choice of icon colours, and where to install documentation - and even better if it remembered where I installed different programs).
* Installation repeatedly failed to install the exif.library , so I had to do this manually. No idea why, as I could do it just fine. (Initially the version check triggered RunInUAE's 68k execution detection, so I suspected this was at fault, but I rebooted & disabled RunInUAE, and still got the same problem.)
* Installation of both Clock & Calendar failed while copying their respective Presets. I believe they fail to create the Clock & Calendar folders in the Presets folder, before trying to copy files to them. BUT I have NOT ruled out this is due to a system patch I had running, so don't spend too long looking for a bug here, unless someone else reported the same issue.
* The RadeonHD.chip files failed to be updated, even though it though no errors were reported. It reported some wierd version number (0 ?) was already installed, so probably the version check is broken. I believe I had the same bug when installing v1.1 :( .
* Why does CANDI want to install it's huge (50MB) of data & image files in the Presets folder? It's own folder would seem a far more logical location. (And the Presets location is also a problem with AmiSystemRestore, since it only allows up to 100MB of restore points... and by default stores far less!)
* As before, it annoyingly wants to install all program documentation in their own separate folders. What's wrong with putting program document in the folders of the programs themselves?
* There is STILL no easy way to tell which system components are new ones, and which ones are replacements for official OS4/Hyperion components. How on earth are OS4 beta-testers supposed to use the Enhancer Software? I can't imagine it'd take more than 10 minutes to add a few (*)s to the Installer to mark which components replace existing ones. (Although IMHO it would have been better to give them a slightly different name in the first place, say "thumblist2.gadget" instead of "thumblist.gadget".)
With the Updater utility:
* It ignores it's own Settings when I tell it to default to "Show Updated" (still starts with "Show all").
* For programs that were NOT installed, it incorrectly reports them as "Updated" (when I presume they should appear as "Not found" since that's an option for "Show"). So I see updates that I should not (with "Show Updated").
* For new system components that were NOT installed, leaving the original OS4/Hyperion versions, it still offers updates. I specifically chose not to install them, so it's confusing & error prone having it offer to update them. It presumably would not be too hard to add a minimum version number check (the first Enhancer Software version), and then list components below that as "Not found".
* It would be helpful if the list had a column indicating their already-installed path, as it seems to use AppDir: to get program locations, and sometimes this is wrong. (It's a bit laborious to have to click on each line & then the Information button.)
You really must have a weird installation to encounter so many troubles in installing ESP 1.3.
I did not run into any problem myself.
Regading installation locations, I see no problem in letting system components being installed on the SYS: partition in the pre-selected drawers. But you can change them during installation if you wish.
How on earth are OS4 beta-testers supposed to use the Enhancer Software?
Since you ask: Beta testers typically have several different boot partitions, at least one of which would be a pure OS4 beta with nothing having overwritten any system components.
Apart from that, when I install programs from the Enhancer pack, I only install one at a time (which requires removing a ****load of checkmarks for everything I am not installing at that time ), and I install as much as possible to custom locations in my Work: partition, just like I do with any other 3rd party stuff (which requires me to do even more meticulous mouse work ). And of course documentation, catalogs and other resources are installed within each program's PROGDIR (yet again more mouse work ...).
This strategy, apart from keeping my system partition(s) as uncluttered as possible, also makes the 3rd party programs available regardless of which boot partition I have booted from.
But I agree, saving off some of the choices for later reuse would make great sense - as would an option to deselect all checkmarks on a page with one click.
* It ignores it's own Settings when I tell it to default to "Show Updated" (still starts with "Show all").
Bug reported/filled.
Quote:
* It would be helpful if the list had a column indicating their already-installed path, as it seems to use AppDir: to get program locations, and sometimes this is wrong. (It's a bit laborious to have to click on each line & then the Information button.)
Just put cursor above item you want and it will popup a bubble help with location (where it checks/looks for it).
Edited by jabirulo on 2017/7/25 10:56:03 Edited by jabirulo on 2017/7/25 10:56:39
My approach to this is to patch the install script replacing SYS: with ENHANCER: (except for kickstart items) and then I have an assign to work:enhancer and duplication of the SYS: directory tree therein.
Some extra 'Assign ADD's in user startup and 90% of things are good to go.
A couple of things don't support multi assigns (usb seems to be one) and a couple of original classes need moving to storage to allow the enhancer versions to work (sound.datatype for example).
I've been quite disappointed by the process involved in updating the Enhancer Software from v1.1 to v1.3, especially since some of these issues were present since at least v1.1 :( .
The method of allowing choice is over complex I agree, see my post above for how I take this matter into my own hands.
Quote:
With the Installer:
* Every time the installer runs into a minor problem (e.g. fails to create a file), the ENTIRE installation process stops, meaning I have to run it again, and laborously re-enter all my installation choices again :( .
This is 'feature' of the installer, as far as I understand, when it encounters an error it aborts, there are some cleanup call back but I don't think you can abort the abort, so to speak. If you know different and have example code or a reference to some, I'm sure Matthew would be interested.
Quote:
(a) Please add graceful error handling, rather than halting installation.
See above. Quote:
(b) It would be great if it remembered/defaulted to my previous installation choices (at least for the main ones like the backup location, my choice of icon colours, and where to install documentation - and even better if it remembered where I installed different programs).
I don't think Installer ofers such functionailty, it could be perhaps implmented with env vars, but this is already the installer from hell! It almost beats the RuninUAE one for complexity! ( ) Quote:
* Installation repeatedly failed to install the exif.library , so I had to do this manually. No idea why, as I could do it just fine. (Initially the version check triggered RunInUAE's 68k execution detection, so I suspected this was at fault, but I rebooted & disabled RunInUAE, and still got the same problem.)
Curious no issue here, which part failed? Library instalation? SDK part?
Quote:
* The RadeonHD.chip files failed to be updated, even though it though no errors were reported. It reported some wierd version number (0 ?) was already installed, so probably the version check is broken. I believe I had the same bug when installing v1.1 :( .
The error in the version check is, I think, a bug in installer, though I haven't had time to veriify and properly report it yet (let alone try and fix it).
Otherwise those component upgraded fine for me, except I was upgrading the 2.x series.
Quote:
* Why does CANDI want to install it's huge (50MB) of data & image files in the Presets folder? It's own folder would seem a far more logical location. (And the Presets location is also a problem with AmiSystemRestore, since it only allows up to 100MB of restore points... and by default stores far less!)
/me points at matthew and sighs
Quote:
* As before, it annoyingly wants to install all program documentation in their own separate folders. What's wrong with putting program document in the folders of the programs themselves?
Generally agree.
Quote:
* There is STILL no easy way to tell which system components are new ones, and which ones are replacements for official OS4/Hyperion components. How on earth are OS4 beta-testers supposed to use the Enhancer Software? I can't imagine it'd take more than 10 minutes to add a few (*)s to the Installer to mark which components replace existing ones. (Although IMHO it would have been better to give them a slightly different name in the first place, say "thumblist2.gadget" instead of "thumblist.gadget".)
Most replacement gadgets etc actually do have different names. Your example thumblist.gadget, is a dependency of ptp.usbfd and not actual part of the OS.
Other like Format, sound.datatype and it's new subclasses, etc must be called with the original names to be found.
But when it comes to te replacement prefs programs I completely agree they should be named differently to avoid confusion and easy revertion to the original.
* It would be helpful if the list had a column indicating their already-installed path, as it seems to use AppDir: to get program locations, and sometimes this is wrong. (It's a bit laborious to have to click on each line & then the Information button.)
Just put cursor above item you want and it will popup a bubble help with location (where it checks/looks for it).
THis is a somewhat slow solution though as bubble help takes a few moments to popup for each component,
My approach to this is to patch the install script replacing SYS: with ENHANCER: (except for kickstart items) and then I have an assign to work:enhancer and duplication of the SYS: directory tree therein.
Yes, I know. But that won't work for me.
First, my Work partition is subdivided into ten different directories, each with programs of a particular type or area, e.g. one for graphics stuff, one for sound and music related programs etc. etc. So the programs I install from the Enhancer, I want to be installed in their correct directories, e.g. TuneNet into the music related one, in a subdirectory called TuneNet.
Second, I do not want to install all programs from the Enhancer, only the ones I find useful (of course I install the ones I translate,so I can test my translations, but coincidentally most of those are more or less useful to me ). So I'm not going to run the installer with default choices anyway.
I could not get Clock and Calendar to install, either. Same issue and ChrisH.
One issue with Format: no REQ command line option like original. From Workbench Explorer I do "SYS:System/Format device=%s req". This selects the drive and goes to the "second" window for name and such. The Enhancer one has to be WBRun with no args and have to pick the drive from list then move on to second window.
Workbench Explorer - A better way to browse drawers
Beta testers typically have several different boot partitions, at least one of which would be a pure OS4 beta with nothing having overwritten any system components.
OK, but before Enhancer Software I am not aware of anything that replaced system files with unofficial alternatives (except for Wazp3D). So I never had to worry about this before.
You still need to allow 3rd-party libraries/etc to be installed to Libs: (etc), or many 3rd-party programs would not work, and so there would be no way to test if an OS4 beta update broke those programs.
@broadblues Quote:
A couple of things don't support multi assigns (usb seems to be one) and a couple of original classes need moving to storage to allow the enhancer versions to work (sound.datatype for example).
I'm not sure about those specific examples, but that general problem is why I wrote a "TrueMultiAssign" patch for OS4. I never released it, because it has some unfortunate side-effects in a few cases.
(This patch allows me to have the original OS4 installation on a separate partition, while all new stuff gets installed to the SYS: partition, however that does not stop the new stuff being used in preference to the original components.)
I will consider using your solution of manually editing the installer, as this sounds easier than my solution of not installing the relevant components.
Quote:
This is 'feature' of the installer, as far as I understand, when it encounters an error it aborts, there are some cleanup call back but I don't think you can abort the abort, so to speak. If you know different and have example code or a reference to some, I'm sure Matthew would be interested.
I do not really understand the Installer's language, but since it was able to jump to code showing a friendly error message, I assume it must be possible to jump to the next part of the installation script instead... (Not saying the code to do this will be pretty, it might not, so I just report the problem & leave it up to the original authors to decide if this is sensible or not.)
Quote:
I don't think Installer ofers such functionailty, it could be perhaps implmented with env vars, but this is already the installer from hell! It almost beats the RuninUAE one for complexity!
OK, I did not check. RunInUAE's installer is WAY too complex AND using a language (AmigaDOS) that was entirely inappropriate for such size, so I regret my installer approach (but now too much of headache to change easily).
I did suspect E.S.'s installer might be overly complex, so I don't necessarily expect my requests to be fulfilled - I leave that up to the developers if it is possible or not.
EDIT: Quote:
Curious no issue here, which part failed? Library instalation? SDK part?
Literally what I said, the "exif.library" file. The target file seems to become locked, so it's unable to replace it. A reboot was required to clear the lock.
Quote:
Other like Format, sound.datatype and it's new subclasses, etc must be called with the original names to be found.
I do not see why Format HAS to be replaced "to be found". Particularly since mritter0 says it doesn't provide exactly the same functionality. It could easily be called "Format2" or "NewFormat" or "Formatter" or "FormatES" or whatever, and let the user choose whether or not they use it in preference to the original.
However, you are I guess right about sound.datatype, but that seems more like the exception than the rule.
this is already the installer from hell! It almost beats the RuninUAE one for complexity!
As I already mentioned, RunInUAE's installed used (what turned out to be) an entirely inappropriate language (AmigaDOS) for what eventually turned into a hugely complex installation script.
But from what I have seen, the classic Installer language (originally provided by Commodore) is not that much better, and is extremely verbose.
I haven't looked at Python, Hyperion's proposed replacement as an installation language, but presumably this has much more modern features, etc. Maybe Enhancer Software should have used this language for their installer?
Myself, I have 'experimented' with compiling an installer using a proper language (E!), but so far not been satisfied with the results (PortablE's installer works but it's not as easy to modify as it should be). I'm hoping that further experience will help me arrive at a suitable abstraction/framework...
I do not really understand the Installer's language, but since it was able to jump to code showing a friendly error message, I assume it must be possible to jump to the next part of the installation script instead...
No, not if I remember correctly. I believe the only such mechanism in the installer language is a sort of "catch" of any errors encountered, directing to a designated label at the end of the program, where you get the chance to print an error, but nothing else. You can't jump back anywhere, you just abort.
Quote:
I do not see why Format HAS to be replaced "to be found".
I guess there might be applications and scripts out there which invoke the Format command by name?
Apart from that, I totally agree with your points about not stomping on existing system bits (at least those that are still being maintained as parts of OS4). If people want to use a third party Format (for example), they can decide for themselves - possibly helped by instructions in the EC - to rename or use other means to redirect calls to the replacement.
Myself, I have 'experimented' with compiling an installer using a proper language (E!)
For me, an important feature of an installer (language) is my ability as a user to read the installation script and convince myself that it does things I want done (and nothing else), or even to change things in the script before running it (e.g. I hate when scripts use "exit quiet" or whatever, so I don't get a chance to save the log). So a compiled installer wouldn't win any points with me.
Speaking of logs, the Hyperion installer doesn't even offer any installation log ... tsk ... And reading the installation script is not directly possible, or at least not easy, since it partly has the form of a XML file.
enhancer update installed ok for me and everything is still working, I didn't try to interfere too much with the installation and virtually went with all the default options. Maybe you guys are over complicating things , just saying. But then I'm not a coder.
For me, an important feature of an installer (language) is my ability as a user to read the installation script and convince myself that it does things I want done (and nothing else), or even to change things in the script before running it (e.g. I hate when scripts use "exit quiet" or whatever, so I don't get a chance to save the log). So a compiled installer wouldn't win any points with me.
My compiled installation 'script' did (of course) include the source code, so I think that solves most of your objections?
I do not see why Format HAS to be replaced "to be found".
Workbench is hardcoded to use "Format" for formatting, so if you want to use ot from the WorkBench->Icon->Format menuitem or from the contextmenu item etc it needs to be called Format.
I personally do not allow that component to replace the system one.
Speaking of logs, the Hyperion installer doesn't even offer any installation log ... tsk ... And reading the installation script is not directly possible, or at least not easy, since it partly has the form of a XML file.
Loggig might be added via the python logging modue, but that does require the install script author to add it.
The xml variant is specific to the SDK installer, which is not the same as the python based "Installation Utility" though might well share code at some level, due the similarity in design.
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
), and I install as much as possible to custom locations in my Work: partition, just like I do with any other 3rd party stuff (which requires me to do even more meticulous mouse work 
)
