Overview of Package Management
Introduction
Package Management is handled by libmagicnimagination.so currently
Why have Exec.platform and not a platform selection field? It might be possible for some packages to contain multiple executables to run on different platforms. Also the platform we're currently targeting is "PS3Linux", not "PS3" since it might be possible later on to have an "OurOS" running directly under LV1. If a package doesn't have an Exec.platform field matching our platform then it's considered to not work for this platform and should be displayed as such in a menu system.
Any strings displayed to the user can be localized by "Field.lang" so "Title.jp" is the japanese title. All strings are in UTF-8 of course :)
Packages
A package is a .deb file containing applications / libraries for OurOS
Bundles
A bundle is a lzma compressed collection of files for a program & or interface to OurOS
Bundle Description
Each bundle should contain a file which describes the bundle... The minimum fields should be:
| Default Fields |
| Name | Purpose |
| Title | The friendly name of the bundle, for display in menus |
| Version | The version of the bundle, so the user can decide if they should update |
| Icon | Path to a PNG image (TODO: decide size) |
| Type | Defines the type of the bundle. Program |
| Category | Tags of Categories the bundle fits in. First tag is considered the Main category |
| Author | Author of the bundle |
| Email | Email to responsible contact |
| Urlpack | Url to where the latest version can be found |
| Exec.PS3Linux | Path to an executable that can run on PS3 Linux (can be a shell script) |
| Date | Date at which the bundle was made, the date of the bundle at Urlpack should match this so we can decide if there's a newer version using a HEAD request |
| Optional Fields |
| Name | Purpose |
| Urlpage | The url to the bundle homepage |
| Description | A long description of the bundle |
| Tutorial | Path to a file or directory with media on how to use the bundle |
Bundle Configuration
Configuration for a bundle is always stored by default under the users home directory. This should come with reasonable enough defaults that the package works as indicated in the description unless there is crucial data missing that must be obtained from the user. This should be requested on first run using a standardized library call so that consistency is maintained in the use of the system. Post first-run configuration can be approached in any manner the package sees fit though again some amount of consistency is encouraged.
TBD: How do Modules approach configuration?