Choose a template
Monday, November 15. 2010
Developers are not usually the right people to write documentation, but in an effort to encourage more Debian folk to consider Emdebian, I'm starting an intermittent series of blog posts to describe how Emdebian works and how it fits with Debian. Emdebian has a variety of ideas and experiments but the principle distribution, to be released alongside Debian Squeeze, is Emdebian Grip. This post, I'll cover the basic stuff. Feel free to let me know if there are particular issues you'd like covered. In particular, if the documentation on the Emdebian Grip website needs improving, let us know.
What's Emdebian Grip all about?
Simply a smaller Debian. Smaller packages, smaller downloads, smaller sets of packages, smaller installation sizes and smaller update sizes; yet always and completely binary compatible with Debian. Every backtrace from an Emdebian Grip device will match the backtrace on a Debian machine of the same architecture, package version etc. Packages can be mixed trivially (with some allowances for strict dependencies like -dbg packages). The name is a derivative of Squeeze - to make Debian smaller, we take a hold of it; Grip it.
Is it cross-building?
NO. Emdebian Grip is not recompiled (natively or cross), it is processed. Packages natively built in Debian are unpacked, files removed and repacked on the server before being included into the Emdebian repositories. dpkg and perl do all the work, not gcc.
What gets taken out?
Translations move out of the source packages and into TDebs (organised by locale) and compiled .mo files are then removed from the binary packages. Manpages and other documentation is lost entirely, copyright is compressed and changelogs are removed. None of the binary files are touched. The SHA256 sum of your /usr/bin/foo executable in Debian will be precisely the same in Emdebian, the same applies to libraries.
How is it done?
The emdebian-grip-server package in Debian processes the package and treats every architecture in the same way. (This allows Emdebian to carry unofficial ports like SH4, armhf etc.)
Why not filter stuff with dpkg?
The straight answer is that there usually isn't room to download the large package first in order to strip it on device. Also, filtering on device is slow. Stripping the package on the server means that the work is only done once. Every Emdebian device is saved the effort of filtering the files one machine at a time. Grip effectively does what dpkg filtering does, just it does it on the server, repacking the results into a new .deb. Instead of every device doing the task again and again, the server does it once.
Why is my pet package not included?
Emdebian restricts the number of packages which are included in the repositories (less than 10% of Debian packages will be included in Emdebian Grip 2.0 which is based on Debian 6.0 "squeeze") but provides tools which can be used (on device or on the desktop) to prepare any other package for installation on an Emdebian Grip device. There is no need for the machine preparing the package to be of the same architecture as the intended device because all processing is architecture-neutral.
Who decides which packages get included?
Me, basically. The merits of adding particular packages is usually discussed on the debian-embedded mailing list. Typical criteria (in rough order) include:
Can I convert Debian to Emdebian Grip
Yes - simply add Emdebian to your apt sources list and watch as your next upgrade releases tens of megabytes of space.
What are these em1 version suffixes?
Emdebian modifies Debian packages, albeit in an architecture-independent manner, by removing files. The resulting packages are therefore different to the originals, albeit containing compatible binaries. Hence, the Emdebian processing adds the em1 version suffix to show which version is installed. Adding the suffix also means that every Emdebian package is considered to be an upgrade compared to the equivalent Debian package, if both exist in your apt sources.
How is Emdebian Grip installed?
It is possible to use Debian Installer (we provide pre-seeding files to help this process) or create a simple tarball using multistrap if that is more suitable for your device.
What about Recommends: ?
Debian defaults to installing all packages listed as Recommends in the package metadata. Emdebian simply drops the entire Recommends field when processing the package. Suggests is also omitted. This dramatically shortens dependency chains and gives developers full control over which packages are installed. It is important here to consider the embedded device user interface. Recommends exists to support those users who need the extra parts of the package, the bells and whistles. Embedded devices strictly control which parts of the package is actually exposed to the user - there is no need for a menu or a desktop. Users can only access the functionality exposed by the device, so no bells and whistles - just the base system and whatever you choose to expose as part of the interface. Rather than require all Emdebian devices to turn off Recommends individually, Emdebian simply drops Recommends at the server and allows the developer to cherry-pick which packages to add.
More to follow . . .
Thursday, November 11. 2010
There must be other organisations across the world which do a similar job but this is the local one for me and in lieu of actually getting to a Remembrance Day event this year (I'll be at a bug squashing event for Debian Squeeze), I'm using my blog, just this once, to express my own thanks to those who gave their lives that I may be free to do what I enjoy, writing code to make things just work.
Thursday, November 11. 2010
Just in passing, if anyone wants to support my work in Debian and/or Emdebian, there is a simple and free way to do it. Send me some patches, especially for documentation, translations and examples.
I have more than enough stuff that I could be doing and I do hear from users who want more stuff done to suit their particular requirements. Sorry, but time is finite and whilst a "thank you" is always appreciated, it doesn't actually generate a 25 hour day. So please don't just tell me what you want or why the current stuff doesn't do what you want it to do. The source code is all just "out-there" and you know more about what you actually want than I ever could.
If any of my code doesn't quite do what you want, please don't moan about it or file bugs that just moan about it, work out why and how and fix it - get involved. That way, the code will develop even if I don't always have time to work on it.
« previous page (Page 1 of 1, totaling 3 entries) next page »