Please CC: me if replying only via the debian-policy list, I'm only
subscribed to -devel, not -policy.
This is meant to be the start of a series of discussions on integrating
Emdebian with Debian. Things started with a query via the DPL about the
status of the Embedded Debian Project and there has been discussion
within Emdebian  about how this should work.
This message is the start of the Policy discussion - a technical
discussion will be a separate thread. (There were informal discussions
about the technical sides of integrating Emdebian Grip into Debian at
DebConf11 with representatives of the ftp, release and wanna-build
teams. Those will form the basis of the technical details.)
Please confine this thread to Policy.
I've tried to summarise the background to this discussion on the Wiki
The aim is to discuss the differences between Debian and Emdebian Grip
. Where Emdebian Policy covers the other flavours of Emdebian (Baked
and Crush) are an extension of these but the emphasis is on the
binary-compatible Grip flavour. (Baked and Crush are very specialised,
indeed Crush is currently stalled until after MultiArch is implemented.)
Also, there is no role for TDebs at this stage. Whilst it is useful to
not completely lose translations in the Emdebian processes, the
expectation is that the "user-visible" part of a device running
Emdebian Grip will typically be custom-software which does not expose
the underlying system messages. Where translations might be useful,
selected files for selected locales will remain available via the
existing Emdebian processes as Emdebian TDebs.
OK: background out of the way, here's the idea.
Emdebian Grip is binary-compatible with Debian but only provides a
selective list of binary packages (with unchanged sources). Files which
Policy-compliant packages provide are removed in an
architecture-agnostic post-build process using the emgrip script, part
of the emdebian-grip package . Files which are a "must" requirement
of Debian Policy are removed. Other "must" requirements of Debian
Policy are over-ridden, e.g. copyright files must be compressed for
Emdebian which reverses that Section of Debian Policy. Some "should"
requirements become "must not". The process of conversion is 100%
automated in an architecture-agnostic process and the changes are,
therefore, applied without regard to the specific package or
architecture. This leads to a predictable set of packages and a common
interface for those times when users may need to pull some packages
from Debian or from internal repositories.
These changes are a direct result of what Emdebian users have
stipulated as necessary for the purposes of making Debian usable on
embedded devices. As a result, the modified packages have found
widespread support from users - commercial and hobbyist.
(Grip is the basis of the other flavours of Emdebian.)
Summary of Emdebian Policy for the Grip flavour (listed according to
the relevant Section in Debian Policy):
3.8 Essential - Packages MUST NOT include the Essential tag.
4.4 Debian changelog : debian/changelog - Debian Policy applies except
that debian/changelog is not included into Emdebian packages, only
retained in the source package.
5.6.9 Essential - Prohibited. No package is permitted to use this
9.8 Keyboard configuration - Note that many Emdebian devices will not
have a keyboard of any kind (except on-screen after installation), so
packages should not use methods that prevent the use of a serial
console or network console or use methods that rely on a physical
12.1 Manual pages - Emdebian packages must not include manual pages.
12.2 Info documents - Emdebian packages must not include info
12.3 Additional documentation - Most additional documentation needs to
be removed. Special consideration might be available for some packages
but the expectation is that all help available to the user is
context-sensitive and localised via gettext (or similar) and implemented
within the application code.
12.4 Preferred documentation formats - context-sensitive tooltips
implemented by the code within the application and localised using
gettext via Emdebian TDebs.
12.6 Examples - Packages must not include examples.
12.7 Changelogs - Packages must not carry any changelog files except in
the source package. Changelogs (Debian or upstream) must not be
12.5 Copyright information - Copyright information must be
compressed with gzip -9. Licences should not be installed by default.
The option to install compressed licences could be provided.
So is it suitable to simply keep EmdebianPolicy as a set of changes
from Debian Policy? Is it better to complicate Debian Policy with a set
08-08-2011, 10:41 AM
applause, thanks & good luck to making grip official!
just one tiny comment:
On Sonntag, 7. August 2011, Neil Williams wrote:
> 9.8 Keyboard configuration - Note that many Emdebian devices will not
> have a keyboard of any kind (except on-screen after installation), so
> packages should not use methods that prevent the use of a serial
> console or network console or use methods that rely on a physical
I think this is unneeded, packages must prompt via debconf already and I
cannot see where a package(s maintainer scripts) would expect a keyboard to be
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com
08-08-2011, 02:16 PM
On Mon, 8 Aug 2011 11:41:06 +0200
Holger Levsen <firstname.lastname@example.org> wrote:
> Hi Neil,
> applause, thanks & good luck to making grip official!
> just one tiny comment:
> On Sonntag, 7. August 2011, Neil Williams wrote:
> > 9.8 Keyboard configuration - Note that many Emdebian devices will not
> > have a keyboard of any kind (except on-screen after installation), so
> > packages should not use methods that prevent the use of a serial
> > console or network console or use methods that rely on a physical
> > keyboard.
> I think this is unneeded, packages must prompt via debconf already and I
> cannot see where a package(s maintainer scripts) would expect a keyboard to be
It's not just the maintainer scripts, it is potentially runtime
processes as well. However, I think you are right. This section was
added as a precaution, it needs to be a piece of documentation rather
than Policy. Debian Policy is quite explicit about what packages need
to do with keyboards but, on re-reading 9.8, it is much more about the
runtime behaviour of terminals rather than relying on a keyboard as an
ever-present method of operation.
Thanks for spotting that one. I've moved that into a note on the wiki.