Task:Maemo Community distribution
 |
This task is in the list of maemo.org development proposals, please help planning and getting it ready for a sprint. Put a note on the talk page if you're interested in helping work on this task. Please see the talk page for discussion. |
 |
A community-provided distribution of Maemo can offer the community more freedom, better options, greater customizability, and better stability than the Nokia-provided distribution. This task outlines the process for putting together a community distribution of Maemo.
Contents |
Goals
Provide a community distribution less encumbered by Nokia's corporate policies that is more flexible in its packaging, bundles community software, and modifies Nokia software and packaging with community patches.
Sort out a repository
It would be preferable to simply distribute all packages in Extras, but this adds complexity and may simply be impossible to do cleanly, as these packages are likely to interfere with SSU and confuse users. Extras-devel is probably more appropriate, but that would force users wanting to use the community distribution to be exposure to unstable software. Not ideal. The simpler and cleaner option is to use a separate repository either on repository.maemo.org or a 3rd party repository somewhere else.
We have 3 options for handling packages:
- Everything is copied wholesale from tableteer to the community repository.
- Pros: Straightforward, easy, controllable.
- Cons: Legal gray area.
- All free components from tableteer are copied to the community repository, but non-free components are fetched from tableteer.
- Pros: No legal issues, no additional effort for Nokia.
- Cons: Increases complexity, reduces control, and exposes users to updates before the community can sanitize them.
- All free components from tableteer are copied to the community repository, and an additional non-free section is added to tableteer.
- Pros: Increased control, no legal issues, cleaner.
- Cons: More effort for Nokia.
After some discussion, it seems like option 3 is likely the most workable. Some scripting could be implemented to help reduce manual overhead, but this is likely a goal for later.
osso-software-version-community
We need to provide a community version of osso-software-version that has a modified dependencies list that provides the community distribution. A couple considerations should be kept in mind, dependencies on proprietary junk will be removed (skype, gizmo, etc.), dependencies will be setup to allow easy installation of updated system libraries and 3rd-party patches (rotation, 48MHz, etc.), and unnecessary packages that shouldn't be part of the OS-proper will be moved to separate packages that can be uninstalled through application manager (bundled PDFs, images, movies, etc.).
Add
Community enhancements that should be added to the default community distribution.
- advanced-backlight: To replace sound and brightness by default.
- bootmenu: For multiboot and USB recovery.
- e2fsprogs: For handling ext2/3 filesystems.
Remove
Useless and proprietary stuff to be removed.
- gizmo-installer: Remove proprietary advertising.
- rhapsody-installer: Remove proprietary advertising.
- skype-installer: Remove proprietary advertising.
Modify
Existing packages that should be enhanced.
- hildon-status-bar-display: Remove from statusbar by default in favor of Advanced Backlight.
- osso-statusbar-presence: Non-mandatory .desktop file
- osso-statusbar-sound: Remove from statusbar by default in favor of Advanced Backlight.
- preinstalled-documentation-rx34/rx44: Move to its own package.
- preinstalled-images: Move to its own package.
- preinstalled-sounds: Move to its own package.
- preinstalled-videos: Move to its own package.
Patches, hacks, and modifications
As a community distribution, we're not burdened by corporate policy and decision making, so we're free to include interesting and useful patches and hacks that Nokia cannot.
Application manager
A community distribution could serve as an easier way to include community branches of Nokia open source applications. The Application manager is a particularly good candidate for this, and could include patches to:
- Disable the legal warning.
- Increase the amount of information Application manager provides.
- Move some of the more useful features out of Red Pill and into the application proper.
- Improve the category view.
bootmenu
Including a modified initfs both increases versatility (by allowing easier multiboot), and gives all users access to recovery modes for when things go wrong. A graphical bootmenu should be put together to increase user-friendliness.
Configuration
By default, a bundled initfs should boot immediately to the default partition, offering a short window to enter recovery mode, but no partition selection. Users can then add partitions either through a .item system on the console with a "flasher" script that commits the appropriate filesystem changes, or through an easy-to-use control panel.
Recovery mode
The bootmenu should offer a number of recovery modes in addition to the existing USBNet recovery. The recovery mode should offer the option to make backup images (to put on one of the cards or other mass storage device), restore backup images, and maybe offer some sort of framebuffer console for use with a hardware keyboard.