They get ran by AmiUpdate. Not all software with an AutoInstall script is on the AmiUpdate servers, but in the case that it is on there in the future, it is ready.
You can use the script manually by extracting the .lha to RAM: then opening a shell window and typing:
They get ran by AmiUpdate. Not all software with an AutoInstall script is on the AmiUpdate servers, but in the case that it is on there in the future, it is ready.
That would be rather silly if you to the trouble of creating an autoinstall script why not ask Rigo for an amiupdate account, he'd be more than keen to give you one.
Quote:
You can use the script manually by extracting the .lha to RAM: then opening a shell window and typing:
RAM: Execute AutoInstall
No you can't, at least not if you want all amiupdate features to work like rollback etc. The AutoInstall script must be called by amiupdate (there did used to be special testing tool but I'm not sure if it's still available).
If you download by hand use the standard installer if present or read the instructions in the software documentation.
Thanks all. So far I just read the autoinstall script and follow the delete and copy instructions by hand, before running any Make commands from shell.
@ddni Some applications when downloaded from os4depot might also, in lack of install script, only require you to copy all files to where-ever you want, and run the program in order to be updateable by AmiUpdate.
Whenever you run a program in AmigaOS 4, an entry is created in the AppDir: entry. This entry is used by some AmiUpdateable programs in order to find where it is located, and check its version.
So, I'd suggest to not manually run the Autoinstall script, nor using it as guide, unless the program's manual tells you to. If not manual or install script is found, I do suggest to contact the developer.
That would be rather silly if you to the trouble of creating an autoinstall script why not ask Rigo for an amiupdate account, he'd be more than keen to give you one.
I've got an account. I use it to update libs on SdkServer.
Quote:
No you can't, at least not if you want all amiupdate features to work like rollback etc.
That's true. I haven't had to use rollback. Yet.
I don't know if TestAutoInstall would work properly for my AutoInstall scripts (it'd pass, but might not represent a real test). I need to make sure that the old symlinks are removed first when updating a library. If you try to create symlinks when they already exist, you end up with issues. You'll see "MAKELINK: object already exists", and the symlink will not point to the new file if the filename had changed.
To clarify, to test the script properly, I need to run it twice, for real.
CopyStore is in the Installer script which is called from my AutoInstall script. It works. I've never tried rollback, although it would probably be more convenient I always forget it exists, so whether that part works or not I don't know.
How else are you supposed to test AutoInstall scripts? Why is the TestAutoInstall archive still downloadable if it doesn't work?
CopyStore is in the Installer script which is called from my AutoInstall script. It works. I've never tried rollback, although it would probably be more convenient I always forget it exists, so whether that part works or not I don't know.
I think the way Rollback is setup has changed since TestAutoInstall was created. Not 100% sure but you might find the binaries you copied with CopyStore don;t appear as entries in the rollback application.
Quote:
How else are you supposed to test AutoInstall scripts? Why is the TestAutoInstall archive still downloadable if it doesn't work?
Last I looked I couldn't see a link to it on the amiupdate website.
The archive might be on the site but there no public link to it (unless I just couldn't see it for looking).
To clarify, to test the script properly, I need to run it twice, for real.
No reason why you can't run TestAutoInstall twice (excluding possible out of datesness of the tool) . It doesn't check for updates / out of dateness of the target, it just runs the script.
If you search Google you get this page which has the file. That must be an old mirror though, as it isn't present in the Downloads section on the proper website.
So how *are* we supposed to test AutoInstall scripts?
I haven't tried TestAutoInstall, how does it work? Does it make a backup of files replaced, then put them back afterwards?
How does it test a "MakeLink" line without actually doing it? If it undoes any actions when it runs, then running it twice is like running it once, twice, instead of actually running it twice. The point of testing the script is to see if I made a mistake in the script. The mistake may only present itself if files or symlinks are pre-existing.
If you have "test.1" as the real file, and "test" pointing to "test.1", then an update to "test" comes around and is called "test.2", the script makes a symlink called "test" pointing to "test.2" yet the symlink already exists from the past installation and still points to "test.1". I need to get rid of this existing symlink first. If I don't, MakeLink will show an error and not update the symlink to the new file.
Surely TestAutoInstall is not just doing "Execute AutoInstall"?
Edit: I tried it. It unpacks the archive, actually runs the AutoInstall script, then does a RollBack if applicable.
It setsup the environment, rollback session etc. The unpacks the archive and executes the script.
It doesn't undo anything. Why would it? the edeveloper needs to inspect and test the resulting install to verify that it is correct.
You can then run rollback or manually revert the component depending what is most appropriate (geberal only binary files a rolledback, but sometimes supporting data migt need to be too). And rerun.
It's a test tool but it's not magic. The important thing is that it does it exactly as AmiUpdate would, or atleast it would do if it wasn't out of date.
I thought "test" in the name meant it did a syntax check and a simulation of the install, without actually doing an install.
Good luck doing a RollBack of symlinks though. I don't think CopyStore can handle that.
It would seem from the AutoInstall scripts I've looked at, that CopyStore is used mainly for the executables, excluding other documentation, catalog files and libraries that go with a program.
It also looks like CopyStore needs to be done on individual files? A bit annoying if you want use it on hundreds of files in a directory. But I think we've got AmiSystemRestore for that sort of thing, which I haven't tried yet.
Good luck doing a RollBack of symlinks though. I don't think CopyStore can handle that.
No but you said your script checked for existing links? So run first time it makes the links. Second time it deals with their presence.
Quote:
It would seem from the AutoInstall scripts I've looked at, that CopyStore is used mainly for the executables, excluding the other documentation, catalog files and libraries that go with a program.
It's up to the script writer I think, generally binaries (which means executables *and* libraries) with versions, as opposed to docs images etc etc
Quote:
It also looks like CopyStore needs to be done on individual files? A bit annoying if you want use it on hundreds of files in a directory.
Quote:
CopyStore.doc said:
We could just as easily use:
CopyStore tunenet/#? "$Tunenet"
which would copy all files in the tunenet directory, and create a backup of each file.
I'm not sure how you set up CopyStore for shard objects (which I'm guessing are what you are writing installers for) when the binary name changes. IT makes abackup of existing binaries via the RollBack database, but a renamed binaray is a "new" binary as far as file names etc go.
a bug fix to lib.so.0.1.2.3 where the name stayed the same would work happily, replacing lib.so.0.1.2.3 with lib.so.0.1.2.4 is essentailly a new binary
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
