Open matteodelabre opened 3 years ago
This may potentially make #21 easier too.
I'm personally unsure if we should do it. While this makes the software more uniform, it makes it harder for newbies/tinkerers or devs that want their sw on toltec as well.
I'm also concerned that we would mess with one of reMarkables own safe-guards (the rollback) and thus could potentially brick devices. Meddeling with updates and uninstalling toltec will also get much harder.
I'm not sure if the increased stability of toltec-software is worth the risk the increased install/reenable/uninstall burden this would add.
I'm not against the idea of building our own oe-image at all though. While we take a bit more space, using a chroot which is partition independent seems like a better middle ground for me personally.
For example, we could have the oe-image installed to e.g. /home/root/.toltec-oe-root
and have bind-mounts from that directory to the real /opt
, /home
, /dev
, /proc
, /sys
. Software that requires predictable libs like qt could then run in the chroot of /home/root/.toltec-oe-root
which would basically behave as the normal device except the predictable libs in their assumed /lib
and so on. This may come at a cost of somewhere around 100MB more storage usage though.
I'm also concerned that we would mess with one of reMarkables own safe-guards (the rollback) and thus could potentially brick devices. Meddeling with updates and uninstalling toltec will also get much harder.
It would actually get easier. Just reflash with the official image.
I'm not sure if the increased stability of toltec-software is worth the risk the increased install/reenable/uninstall burden this would add.
In my opinion it would be. I'd like to be able to take xochitl updates without breaking all my other stuff. This would be a mechanism to do that. We could run the system image in a chroot or something and flash updates without breaking all the other apps. And install/uninstall would become easier, and there is no longer a need for reenable.
It would actually get easier. Just reflash with the official image.
You mean with the flash utilities?
In my opinion it would be. I'd like to be able to take xochitl updates without breaking all my other stuff. This would be a mechanism to do that. We could run the system image in a chroot or something and flash updates without breaking all the other apps. And install/uninstall would become easier, and there is no longer a need for reenable.
Ok. I think that I don't fully understand the goal then, yet. It is cool if we can ditch the reenable though. Since I don't fully understand it, I'm not in a position to doubt this decision and I should probably just let it happen.
Just curious: Would this change the scope of toltec from a packagemanager/repo to a fully blown distro that devices could run instead?
You mean with the flash utilities?
That or just booting into the other root partition and writing the official image to the other partition. We'd probably want to create some tools to simplify things.
Ok. I think that I don't fully understand the goal then, yet. It is cool if we can ditch the reenable though. Since I don't fully understand it, I'm not in a position to doubt this decision and I should probably just let it happen.
This is probably a ways off still. We'd have to figure out the whole image first and what is required etc. Plus we'd have to sort out how to run the chroot with the official image for running xochitl and having it play nice still.
Just curious: Would this change the scope of toltec from a packagemanager/repo to a fully blown distro that devices could run instead?
Yes it likely would. That's why this issue is titled "explore" and not "implement". There is a lot of things we have to sort out first to see if it's worth it. I do think in the end it might be though.
Instead of installing apps in the
/opt
folder of the stock system, we could build a custom system image with OpenEmbedded/Yocto and take advantage of the dual-partition setup to install our image in a partition while keeping the official image in the other. The company has published some of the recipes used to build their OE image:This could allow us to control the libraries included on the system and to more easily create the build toolchain since OE can export a toolchain automatically IIRC.