Package Management
Contents |
Mission Statement
The goal is to make package management via opkg work on the Pandora platform. The package management system must be able to handle changes and removal of storage media gracefully as well as allow easy installation of packages when the device is not connected to the internet. Down the road this will enable functionality that can reasonably expected from a modern linux distribution, such as GUI browsing of the repository, update notifications and automatic updates.
It is believed, that a well designed package management system will lead to a better user experience for users of all proficiency levels, that it will lead to a broader range of applications for the platform, that it will lead to greater acceptance of the platform within the linux community, that it is less prone to user error, and that it will make the lives of users, administrators, community supporters, developers and package maintainers easier. Ultimately it may even bring along world peace.
Roadmap
Proof of concept
- Set up an unionfs on top of the barebones software image.
- System will be able to boot into barebones and function normally without SD card, from the user's perspective it will be indistinguishable from the default pandora image.
- SD card can be inserted and mounted on top of the nand
- Package management can be used to install software on the unionfs, barebones system remains intact, as nand remains unchanged.
Pre-fabs
- Pandora boots into barebones system.
- System detects SD cards, offers a user-friendly way to gracefully mount them on top of the barebones image.
- Also handles unmounts gracefully without requiring reboot.
- This will allow user to use package management system to create pre-fab meta-packages that allow him to extend the functionality as needed. E.g. you could have an office and games pre-fab SD card.
Brainstorming
Handling dependencies on removable media
Every medium has its own independent installation of the package manager and package database.
Say, you have /nand /sd1 /sd2, normally they are joined with unionfs to / so they look like a single file system. However when opkg is run, it is actually a wrapper script which will ask where the install should be performed, then chroots into that medium and calls the "real" opkg.
This will avoid dependency hell. Say you have programFoo which depends on libBar. You want to install programFoo in /sd1, but libBar is already installed on /sd2. By chrooting into /sd1, libFoo on /sd2 will be invisible to opkg and thus, will be installed as a dependency on /sd1. This way /sd2 may be removed safely without breaking programFoo in /sd1.
Packages that are contained on the barebones system on the nand can be assumed to be always present.
see other proposals
