Create a more robust binary distribution system
The current AppInstall system has a number of positive attributes:
- Simple for end users
- Easy AppImage creation for developers with a simple GUI
- Self-contained collection of (almost) all dependencies.
However, it has historically been a bit buggy and, in part due to its dependencies, it has severe problems with multi-arch distributions.
It would be ideal if we had a system to create binaries which were just as easy for the end user to run, and at least as easy for developers to create/maintain, but without the technical complexity of AppImages. I believe that this complexity is what inevitably leads to maintainability and compatibility issues.
Therefore I propose a KISS-type system. It's easy enough to create a shell script containing a self-extracting binary. The question is: what next? How would that binary work? How would we implement it to simply perform all the functions in the current AppImage system? Perhaps the distribution shell script could unpack the Ember directory structure into a temp directory and run it from there? Part of the current problem with AppImage is that its directory structure is an embedded ISO filesystem. This invariably leads to the complexities which that system necessitates. The problem (a problem) I see with extracting to temp and running from there is that there will be an initial delay while a few hundred MB is copied over.
Anyone else have any thoughts on this subject?
Blueprint information
- Status:
- Started
- Approver:
- Erik Ogenvik
- Priority:
- Undefined
- Drafter:
- Olek Wojnar
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Discussion
- Series goal:
- None
- Implementation:
-
Needs Infrastructure
- Milestone target:
- None
- Started by
- Olek Wojnar
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
- Here's a possible solution to the loading delay: we could copy media files to the user's home directory so that they would not need to be extracted in the future. This wouldn't help with the initial run but would allow subsequent runs to be much faster. The downside is that this copying would need to take place for each user. The upside is that most people don't have too many users on the same computer. -ow
-What precisely are the cons of using AppImage? It's clear that this is a complex issue, and I'm just afraid that by doing this ourself we'll spend resources on something AppImage anyway is working on. I.e. I'm not convinced there's a value in doing this ourselves rather than working with existing solutions such as AppImage. /erik
- Good question. The biggest issue is their packaged binaries and the overall complexity of the system. The glibc versioning issue that keeps coming up is related to that. The more complex pieces you have, the more chance for things to break. And they do. Also, having worked with it a bit "under the hood" the system is not very... clean. However, I completely agree that we should not be inventing something from scratch. That's what other open source projects are for! ;) I don't mind digging around a little. Now that I'm a lot more familiar with AppImage and its strengths/
