Hello.

Yes I'm getting annoyed at all the broken AmiUpdate packages that haven't gone through a basic check and are accepted onto the server. This has been going on for years and it's got to stop.

So here is an old example that is still present. tuneaac_plug.lha. It's broken. Obviously abandonware since the author hasn't fixed it. Nor tested it. And Simon doesn't want to fix other peoples problems on his third party database. He already provides the server and client.

So this is what commonly appears in the log:
No AutoInstall script found.

I mean, dude, how hard is it to check that file exists before uploading?

There is even software on the depot that has an AutoInstall script. Though funnily enough some of that software doesn't have an actual install script of its own. So is a bit backwards.

It would be good if there was a validation tool on the server, that unpacked archives and checked for this script, then rejected it if it was missing.

The latest example is the AmiSSL4 update I just found. Good to see an update. But how about a working update, is that too much to ask?

Here's a short tutorial on writing an AmiUpdate package.:
1. Include an AutoInstall script in the root of your archive that launches your installer.

Wait, there must be more steps, it can't be that easy.

@Hypex

Actually there ARE more steps to be done.

It doesn't help if you just place an autoinstall script in your package...

@Hypex

Also note that the AmiUpdate server itself does not (normally) have the actual software on it, it only has the information telling AmiUpdate where to find the software, and which files to check to see if it needs updating etc.

So when you e.g. see an archive on OS4Depot with an AutoInstall script in it, it's probably because that's where the AmiUpdate database points to, so AmiUpdate gets the archive from there when updating.

It is of course the responsibility of the author to make sure the AmiUpdate database entry for the product is correct, and to make sure the archive pointed to by that entry is available and has the expected contents.

Edit: As for the AmiSSL package, I don't think you're quite fair. AmiUpdate tells you about the update being available, and downloads and unpacks it for you (depending on your settings in Prefs/Updates). It then tells you that the archive has been stored for further action by the user. How hard is it to open the drawer and double click on the install icon?

I think it is much more reasonable to criticize the archives which *do* have an AutoInstall script, but where it fails because it expects files to be present in the archive which are not there, or similar crap, which could have been fixed by testing the installation properly.


Best regards,

Niels

Last edited by nbache on 12-Feb-2017 at 05:51 PM.

@nbache

You are spot-on, i'm still pondering myself if i should add an automatic installation (Autoinstall) to a porting project of mine through AU or just let it download the package for the user to decide to either start the installer which is inside or copy the stuff manually.

Problem is that the program has seen many releases without AU support and it might (will?) break something on some obscure user installations as the autoinstall script can't know all possible combinations a user can think of...

Still not decided yet

@nbache

Quote:

It then tells you that the archive has been stored for further action by the user. How hard is it to open the drawer and double click on the install icon?

I can do that and that's what I ended up doing but I used AmiUpdate specifically to do the work for me. Since it appeared as an update. After it downloaded it said there was a problem. If AmiUpdate supports a case of download and manual install then a window should pop up telling me so and the window open for me on Workbench.

All I see is a message that something went wrong and an error in the log. I picked AmiSSL simply because it was the latest one to do this. It wasn't personal.

We could judge what is a fair and reasonable criticism of an AmiUpdate package but my point would cover all broke packages, be that missing install script or other files. iSpell has annoyed me for years as well. Whatever it does not update my existing one. And AISS has a bug in the AmiUpdate version file on my FE volume for some reason.

@Hypex
FYI: AmiSSL installer puts the new AmiSSL documentation in SYS:Documentation instead of SYS:Documentation/AmiSSL which could lead to users reading the wrong docs for the AmiSSL V4. I've already added this to the bug tracker at the AmiSSL repository.

Visit https://github.com/jens-maus/amissl/issues to report any issues with AmiSSL. Do it soon if you want it to be fixed in upcoming update.

Last edited by Xenic on 13-Feb-2017 at 03:26 PM.

_________________
X1000 with 2GB memory & OS4.1FE

@Hypex

Quote:

but I used AmiUpdate specifically to do the work for me.

In that case you are probably expecting AmiUpdate to be something it isn't necessarily meant to be.

The original purpose of AmiUpdate, at least the way I recall it, is to make sure you don't miss updates to your applications. The possibility to use the AutoInstall functionality came later as an added feature.

Quote:

All I see is a message that something went wrong and an error in the log. I picked AmiSSL simply because it was the latest one to do this. It wasn't personal.

Neither for me; I don't have any involvement in the AmiSSL project. But my point is, you have to differ between buggy scripts which leave you with half-done installations, and archives where it was deliberately chosen to not have an AutoInstall script, but instead use an installation process which is compatible with all platforms (AmiUpdate is only for OS4).

BTW, the AISS update is similar, it doesn't provide an AutoInstall script, but has its own installation script which at least for me has worked fine on the over ten system partitions I have installed it on so far. What bug are you seeing with it?

Best regards,

Niels

@Xenic

Good idea.

Oh no... now getting annoyed at broken websites on Amiga browsers...

@nbache

Quote:

In that case you are probably expecting AmiUpdate to be something it isn't necessarily meant to be.

Well that's what I've been using it for since some years now. And for the most part it's worked fine. It's the closest I've seen to a package manager.

Quote:

The original purpose of AmiUpdate, at least the way I recall it, is to make sure you don't miss updates to your applications. The possibility to use the AutoInstall functionality came later as an added feature.

That sounds like a notification feature. I used to read Amiga sites a bit so would have caught news of most updates. And for programs I use that have some issue always used to check for new versions.

Quote:

But my point is, you have to differ between buggy scripts which leave you with half-done installations, and archives where it was deliberately chosen to not have an AutoInstall script, but instead use an installation process which is compatible with all platforms (AmiUpdate is only for OS4).

In that case, unless I missed it, there should be some flag the uploader can turn on, so AmiUpdate doesn't look for the script and give error. It looks like it's almost there.

Quote:

BTW, the AISS update is similar, it doesn't provide an AutoInstall script, but has its own installation script which at least for me has worked fine on the over ten system partitions I have installed it on so far. What bug are you seeing with it?

I have a few AISS archives and most include an AutoInstall script. Even one from 2008.

But the bug. It's on my X1000 FE volume. AmiUpdate says the version string is of ENV:AISS is incorrect or missing IIRC. That file exists but it's 20 bytes long and has a version string with zeros padded on the end.

Also there is another issue. AISS cannot be installed from scratch. For whatever reason my TBIMAGES: assign is gone. So trying to install AISS myself using any installer it comes with does not work. I downloaded it off AIFF site and tried various versions of the installer I found inside and all were broken for my system. All ones I tested assume the assign exists which is silly. How does it install itself to a fresh system? I sent an email to Mason but got no response. Perhaps the web form spammed me.

Though this is going slightly off topic. I can fix it myself obviously. But something has corrupted it and I'd like to know what. I don't like a DIY fix in these cases as it doesn't solve the issue but works around it and erases the evidence. I keep that system clean as possible so don't know what happened there. As well as that version file. What writes to it I wonder? I need a direction to point my finger too.

@Hypex

Quote:

Also there is another issue. AISS cannot be installed from scratch. For whatever reason my TBIMAGES: assign is gone. So trying to install AISS myself using any installer it comes with does not work. I downloaded it off AIFF site and tried various versions of the installer I found inside and all were broken for my system. All ones I tested assume the assign exists which is silly. How does it install itself to a fresh system? I sent an email to Mason but got no response. Perhaps the web form spammed me. Though this is going slightly off topic. I can fix it myself obviously. But something has corrupted it and I'd like to know what. I don't like a DIY fix in these cases as it doesn't solve the issue but works around it and erases the evidence. I keep that system clean as possible so don't know what happened there. As well as that version file. What writes to it I wonder? I need a direction to point my finger too.

By default in a stand AmigaOS4.1 install (any version) the user-startup looks like so:

;BEGIN MUI
If EXISTS SYS:MUI
  C:Assign >NIL:     MUI:    SYS:MUI
  C:Assign >NIL: ADD LIBS:   MUI:Libs
  C:Assign >NIL: ADD LOCALE: MUI:Locale
  C:Assign >NIL: ADD HELP:   MUI:Docs
EndIf
;END MUI

assign tbimages: SYS:Prefs/Presets/tbimages

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@Hypex

Quote:

In that case, unless I missed it, there should be some flag the uploader can turn on, so AmiUpdate doesn't look for the script and give error. It looks like it's almost there.

It does not "give an error" it logs the absense in the log, that's entirely different. AutoInstall scripts are not compulsory, and the absense of one is not an error.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Quote:

By default in a stand AmigaOS4.1 install (any version) the user-startup looks like so:

Yes that's what mine usually have. Though I would prefer it to be more neat.

A problem with that is putting contribs as part of a standard startup script. Really they shoud be added as part of the installation process. Using an installer tool that can manage these scripts.

What I think should be done, and should be in place now, is to depreciate the User-Startup script and instead have a Startup directory that contains files to execute startup scripts. I notice Linux has also moved in this direction. And this would follow on from AmigaDOS2 where Mountlist was migrated into DOS Drivers. The idea can be and I think should be extended to assigns and paths. That is an application just needs to copy files into a certain place to be set up. And to be removed its files deleted. No need for any tools to add and remove lines form a rigid text file.

Last edited by Hypex on 15-Feb-2017 at 09:36 AM.