this is as expected…
there are two steps to installation of a zop:
unpacking the contents (including verification of integrity)
running the deploy script (for post install configuration)
it always unpacks to the ‘current user dir’
to do what you want to do, you could make deploy.sh move the patch afterwards
(you’ll see i do this for quite a few system scripts , where I move things from /Patches to /System, its the same principle)
however, some caveats:
/sdcard is only for patches, and will not exist for many organelle-1 owners.
(this was introduced only in 3.x, and was optional , since its only possible with a larger sdcard than supplied)
b) is it desirable?
the current method, means that the usb stick can be used for ‘different setups’ - this is why it completely overrides the ‘user dir’.
c) will it make sense to the user?
because of (b), if you take the patch from the usb drive and put it onto the sdcard,
the user will not *see the patch in the patch menu until they eject the drive.
Im not quite sure why you are wanting to do this… but on the surface I think it could lead to confusion.
thats not to say I don’t think there is isn’t some room for improvement here - but I think it should be in the core OS/mother host.
the current sdcard support is really built around using wifi to manage, as this is the mechanism I use.
however, I did mean to add some support on the organelle for managing sdcard <–>usbdrive.
primarily so that a user could use a usbstick to install to the sdcard, when they did not have wifi.
(which i wonder if this is what you are trying to do?)
I can see 2 things that could work well.
A) install target
the organelle, could detect the usb stick being inserted, and see a zip/zop in the root directory. and then offer to install that to the sdcard. - in this ‘mode’ the user is not mounting the usb stick with reload, so its not see as a ‘user drive’
B) sync usb
this would allow the sdcard to be synchronised to the usb stick.
potentially this is useful for:
- re-organising the sdcard patches without a computer.
I was going to put this in when doing 3.x, as its a simple rsync, but there’s a couple of ‘issues’
- its going to be pretty slow, as the usb read/write speed is not that fast, this means really you want some kind of user feedback.
- sync’ing is never perfect, whats the strategy?
who is the master? e.g. if I see a patch on the sdcard but not on the usbdrive… should I copy it to the usbdrive (sd=master) or remove it from sdcard (usb=master)
and you can’t really just ‘make the user choose’, because they quickly get confused about the process.
and to make matters slightly more complex, file dates and times are only reliable if organelle had a network clock source.
upshot is… I think
(A) Would be really useful for some, and is pretty simple to do.
(B) I’m not so sure about, it could lead to more confusion than solving problems,
but perhaps two simple options ‘Sync FROM usb’ ‘Sync TO usb’, might work.
I do think they are both valuable additions to the mother host, as I think quite a few are still using USB sticks… and it be great to migrate more users over to the SDCard as, imho, its a much better experience and also more reliable.
(note: as above, I think keeping current usb functionality as user drive is very useful for ‘different setups’)