EmdebianMetaData
The biggest remaining issue in making [:Embedded_Debian: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.
The issues have been developed in discussion with emdebian and debian developers at the Extremadura Work Session, Debconf and LinuxWorld Expo, in 2006 and further optimised at Fosdem 2007.
Composite method.
emdebian diff contains changes that are implemented via patch files kept in svn superimposed on the Debian diff, managed with emdebian-tools. Emdebian diff applied after debian diff, then standard build tools used on the result. i.e. The upstream .tar.gz needs to be debianised to make a working Debian package, then the Debian package can be emdebianised. Patch files can be reversed to regain the original Debian package.
pros
- No changes to tools. (Wrappers are available in emdebian-tools for a standardised approach.)
- Avoids duplications of files/info - all changes are patches
- Changed packages have changed version string so no confusion over functionality
- Changes clear to all, so easy to send upstream
- Build logs generated and stored in SVN, simple to compare against Debian logs.
- keeping only patches in svn makes it easy to manage multiple version of packages and
- uses standard, familiar tools yet provides flexibility
cons
- not as simple to use/understand as some of the other schemes
Mechanisms:
- 1 Use of an appended emdebian version string with the 'em' prefix and a sequential digit: Example: if epoch = 1, upstream version = 2.3.4, debian version = 5, NMU number = 6, emdebian version 7, built for emdebian on arm:
{{{ foo_1:2.3.4-5.6em7_arm.deb foo_1:2.3.4-5.6em7.diff.gz foo_1:2.3.4-5.6em7.dsc foo_1:2.3.4-5.6em7_arm.changes }}}
- In common with Debian versioning itself, the emdebian version resets to 1 each time a new package is available. Emdebian considers Debian as upstream so a new Debian version is still a new package as far as emdebian is concerned. This achieves three distinct ends.
- Separates the emdebian archive files from other Debian archives and associated files being built from the same source tree on the developer system.
Identifies the archive as an adapted, stripped out, archive that is not necessarily compatible with any other .deb or .udeb files or programs.
Allows emdebian developers to have a version number that is independent of the full Debian version string.
Status: All already achievable with normal Debian tools. emdebian-tools scripts act as standardised wrappers.
Problems:
- Wherever possible, emdebian will use standard Debian packaging scripts - only tweaking those related to the content needing to be removed or ignored in emdebian packages. i.e. the burden of changes has moved from Debian developers to emdebian developers. Packages like apt-cross and dpkg-cross can be further enhanced to ensure the correct versions of the debhelper tools are used. Overall, this leads to changes in fewer files than using the $DEBIAN_DIR approach, as well as less duplication.
Those packages that need further customisation can have patches stored in the emdebian SVN repository. The emdebian build script - emdebuild - will checkout and apply the patches before debian/rules is called. This is vital because using existing patch methods like CDBS and dpatch relies on debian/rules being called to perform the patch. In order to successfully patch debian/rules itself, the patch process needs to begin before debian/rules is called. The repository holds patches on a per-source basis.
Status: Implemented in emdebian-tools, currently in Debian unstable.
- Unlike Debian packages, emdebian packages will not have individual emdebian maintainers. Instead, any emdebian developer will be able to update the emdebian customisations for a particular Debian package, e.g. when a new version is uploaded to unstable.
- An emdebian buildd can then package and upload archives to the emdebian repository to remove the delay between packages reaching testing and being built for emdebian.
Overall, this method uses the best of each of the previous ideas but large amounts of work remain.
A useful thing to do would be set up an emdebian BTS. Repackaging Debian archives through automated systems can cause mysterious bugs.
$DEBIAN_DIR
<explanation/example> - used by STAGv2 and STAGE
con:
- Needs updated tools (dpkg, debhelper, etc). This has been implemented (June 2006) but there is serious resistance to the concept from the maintainers of the existing Debian packages (dpkg, devscripts). Having to maintain these packages separately is a real disadvantage.
- Repetition of info in two or more places
- 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.
- Easy for package maintainers to ignore so will get bitrot
pro:
- 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
udebs
<explanation/example> - used by Debian-installer
con:
- Harder to make specific variants due to close integration with Debian proper / no overlay mechanism
- Changed package names require different sets of packages for 'embedded' base system.
- Debian packages will not install due to wrong deps (see pro)
pro:
- Easy to get changes into standard packages - mechanism is accepted, separation is clear
- Changed packages have changed names so no confusion over functionality
- Good acceptance in Debian proper already due to Debian-Installer team work
- Debian packages will not install due to wrong deps (see con)
- Needs changed build tools to understand it (dpkg, debhelper etc) - such tools/changes are already in Debian
Just change /debian files
con:
- 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
pro:
<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