Revision 1 as of 2006-04-14 15:14:06
|Deletions are marked like this.||Additions are marked like this.|
|Line 37:||Line 37:|
The biggest remaining issue in making Embedded Debian is how to store and control package metadata which describes how to reduce package size, increase granularity, reduce the size of the essential package set, etc.
This page tries to document the issues and the pros and cons of the current active proposals.
$DEBIAN_DIR <explanation/example> - used by STAG and STAGE
- Needs updated tools (dpkg, debhelper, etc)
- Flexible and hierarchical - easy to apply a set of local changes
- Easy to build entirely standard packages when $DEBIAN_DIR is set to debian
- Changes are cleanly separated from standard package
- Quite easy to understand
- Repetition of info in two or more places
- Easy for package maintainers to ignore so will get bitrot
- Generates packages with same names as standard packages but different files/functionality/interface - will cause problems if mixed with Debian proper, or with different distros using the same mechanism.
- Debian packages will install, but may not work due to missing files.
udebs <explanation/example> - used by Debian-installer
- Ensures that changed packages have changed names so no confusion over functionality
- Easy to get changes into standard packages - mechanism is accepted, separation is clear
- Good acceptance in Debian proper already due to Debian-Installer team work
- Changed package names require different sets of packages for 'embedded' base system.
- Debian packages will not install due to wrong deps
- Needs changed tools to understand it (dpkg, debhelper etc) - such tools/changes are already in Debian
- Harder to make specific variants due to close integration with Debian proper/ no overlay mechanism
Just change /debian files
<explanation/example> - used by SLIND In fact this is really a variant of the $DEBIAN_DIR example and could be implmented that way too (this assertion needs testing)
- Simple - easy to understand
- Standard tools will work
- Very difficult to push changes back into standard packages - most are not appropriate
- Large maintenance effort (due to no mechanism for pushing back into standard Debian packages