Some people reported issues upgrading Icaros Desktop 1.3 once installed onto a pendrive. In practice, what happened to them was that LiveUpdater could update just bare AROS system files, but not stuff inside the Extras and Development drawers. I had a long discussion with a user on the Amiganews.it website forum (whose nickname is... Amiga!) but in the end, with his precious aid and patience performing all the silly tests I asked him to do, we could target the bug and find a solution to it. I am not sure I will release a patch, but I will tell you how to fix it by yourselves. It may be even funny. First of all, remember that this issue impacts only installations on USB pendrives, whose system volume label is "AROS Live Drive" (the most common situation for USB system keys), but people using Icaros on the hard drive won't have to change anything.
1. Just run the text editor and load these two files: SYS:Tools/LUPD/LiveUpdater and (optionally) SYS:Tools/LUPD/LiveDaemon.
2. search for these lines
cd ${EXTRASPATH}//
cd >env:OTHDEST
assign othdest: ${OTHDEST}
3. add double commas (") before and after ${OTHDEST}, this way:
assign othdest: "${OTHDEST}"
4. do this on both files, save and quit.
And now a little explanation, for people fashinated by these topics. LiveUpdater needs to create two temporary assigns for system files (sydest:) and for extras/development stuff (othdest:). While assigning sydest: is really simple (it just replicates sys:), making the right choice for othdest: is a little more trivial, since users during AROS installation can make different choices. They may decide to create the work: partition and install extras stuff there, but they may also decide to create work: but still mantain the extras stuff on the system partition. Using partition names like DH0: or DU1: might create only issues, so the best thing I thought to do was:
a) move the shell to the parent directory of the path inside the EXTRASPATH system variable
cd ${EXTRASPATH}//
b) place the current path on the env:OTHDEST variable as well
cd >env:OTHDEST
c) assign othdest: to the path written in the OTHDEST variable.
assign othdest: ${OTHDEST}
What I didn't keep into account was the strict relation between partition and volume names in the shell. For instance, on a hard drive DH0: is generally bound to AROS:, while DH1: to Work:, and if you give a command like "cd DH0:", you will end up prompting into "AROS:", not "DH0:". So what happened exactly when running these three lines on a pendrive?
a) the first line read "DU0:Extras" in env:EXTRASPATH, so changed directory to the parent DU0: volume. In this case, "AROS Live Drive:"
b) the second line wrote "AROS Live Drive:" (and not "DU0:" like I stupidly expected) in env:OTHDEST
c) as a conseguence, the third line was executed like if it was
assign othdest: AROS Live Drive:
which is WRONG. This way, the command parser tried to assign othdest: to "AROS" and ignored the rest, since it encountered a space afterwards. Obviously, the script ended up in a window asking for the "AROS" drive, which happened to be even more misleading, since "AROS" is also the normal name of the system volume, on hard drive installations. Placing two commas like I suggest, however, fixes the issue. The third line gets correctly interpreted as:
assign othdest: "AROS Live Drive:"
...so the parser knows that the right path is the one included between commas, spaces included. Sorry for the silly bug and all head-aches it could bring. I've already corrected it for next Icaros releases.
