I think it would be nice to see more complete Linux uninstaller capabilities in the SDK install package.
I'm downloading and installing the Linux version of the SDK today and I read through the README.md and setup.sh script just to verify that everything was above board. I liked what I saw for the installation process, but I noticed that there was no real capability for cleanly uninstalling the software in the download package.
I saw that there's an existing thread for uninstalling the SDK on Steam Deck, but the advice there is simply to delete the SDK folder and a few other files by hand. This wouldn't address reverting the udev rules that the setup.sh script sets, and perhaps there are other things that would be missed too. To have a complete and clean uninstall, a Linux user would have to reverse-engineer the setup.sh script, and then undo each step.
Undoing the steps may not be that hard, but I think it would reflect a more responsible app deployment to also include an uninstaller script of some kind for Linux. Please let me know if you have any more refined or recent advice for uninstalling the Playdate SDK on Linux.
Thanks for considering my feedback! I hope it's helpful. I'm excited to get tinkering with Playdate!
Eventually we'd like to move setup to flatpak or some other package. However, an uninstaller would be a nice. With the udev rule specifically, some users would already have that set up and we wouldn't want to undo that change blindly so we'd need some sort-of state tracking which would require more that what we have now. Thanks for the feedback!
I totally understand. I was thinking something similar about the udev rules. I think distributing in flatpak or some similar packaging technology would be awesome!
Thanks for getting back to me on this! I appreciate the engagement from the dev team.
Eventually we'd like to move setup to flatpak or some other package. However, an uninstaller would be a nice. With the udev rule specifically, some users would already have that set up and we wouldn't want to undo that change blindly so we'd need some sort-of state tracking which would require more that what we have now. Thanks for the feedback!
It works, except for the udev rule and (presumably) connecting to a device. Alas, I, don't have a device to test with just yet. But my plan for that would be a note in the README about how to add the necessary udev rule on the host. Could provide a bash script that adds the necessary system configuration, and adds a flatpak override allowing date.play.simulator to access arbitrary devices.
Other than that, I'm maybe 90% happy with it. Should be possible to build and run the thing on any Linux desktop with flatpak available. The manifest file tells a lot of it, but I'd be happy to provide some notes about what issues I ran into. We could get to "good enough" with, I think, relatively easy fixes on the Simulator end
Interesting! As you've found, Flatpak is a bit too restrictive for doing things like installing a udev rule (and perhaps even reading the serial port, I haven't gotten that far in my investigation). On the other hand, I've successfully created a .rpm file for Mirror and will be looking at .deb this week (which I'd bring over to the Sim). I know flatpak is the cool way to go, but given the OS integration issues it might be simpler to go native packages for now.
Yeah, that makes sense. Making it install nicely to the system will be a big win there!
For what it's worth, the device=all sandbox hole should be enough for reading a serial port. It means an application like GNOME Software will end up showing a scary warning label (since that's a pretty big sandbox hole), but I don't think anyone would be shocked to find a development tool needing to do scary things. There is sort of a desire to make a thing over here: Add USB device access portal · Issue #227 · flatpak/xdg-desktop-portal · GitHub. But, eh.
The weirdest frustration for me with the flatpak was figuring out how to appease the Simulator writing files under SDK_DIR/Disk (even when SDK_DIR isn't writable). I imagine that is something you'll end up solving nicely building a DEB or an RPM as well since those same files will end up off limits, so, I'm definitely looking forward to that since I'll be able to remove that awkward wrapper script
