On Thu, 26 Aug 2010 00:49:55 +0200 Guillem Jover <guillem@debian.org> wrote: > Hi! > > Not sure if what's on the Emdebian Policy [0] is considered up-to-date It is up to date for the release which it covers - Emdebian Crush 1.0 based on Debian Lenny - I've tried to clarify that on the wiki page. > or not, but it seems it might benefit from some changes, which could > simplify it quite substantially, and also reduce the divergences > Emdebian needs to perform to stock Debian. Yes, there are changes compared to what Debian currently does, but unlike Debian, Emdebian Policy is primarily governed by the cross-built, stable, Crush release. The state of cross-building support / Multiarch in Debian for Squeeze is such that there is no current development of a cross-built Emdebian package set and hence no driver for changing this particular area of Policy. I've split that document so that it has sections covering Emdebian Baked and Emdebian Grip. Grip is binary-compatible with Debian (and therefore allows perl and other interpreters), so that will use whatever support dpkg normally provides, subject to the Policy for Emdebian Grip. Baked is one step on from either Grip or Crush, forcing a static configuration and removing all means to update the configuration at runtime. (Just as one cannot reverse the process of baking a cake to return to eggs & flour etc., Baked is a uni-directional process - modification requires sending the entire install to /dev/null and re-installing wth the mods. It's quite conceivable that Baked could run read-only, requiring a boot-time option to allow the unit to be "flashed" with a new Bake.) > In latest dpkg.deb all programs are either in POSIX shell or C, which > includes dpkg-statoverride (1.15.5), dpkg-divert (1.15.8), merging > mksplit back into dpkg-split (1.15.8) and update-alternatives > (1.15.8), so no Perl programs anymore, which means these can be used > just fine. This is a welcome change, unfortunately Emdebian Crush will need to wait until after the Squeeze release to make use of them. (Probably wait until after Multiarch supports cross-building TBH.) > Latest dpkg supports path filtering too, which can be used by dropping > a configuration file under /etc/dpkg/dpkg.cfg.d/, and could avoid > having to repack and strip undesired content from binary packages. This can be useful but does still mean downloading the .deb binary package containing all the stuff that gets immediately thrown away and can dramatically extend the time required to both download and install non-Policy compliant packages on-device, especially when using SSD storage. Hence, dpkg filtering will be used alongside existing Emdebian Grip processes. The primary means of implementing Emdebian Grip Policy will remain stripping non-Policy compliant files from binary packages on the mirror, filtering being reserved for one-off updates or for compatibility reasons. > Packages calling install-info should stop doing so in Debian, as we > should be using the triggerized support nowadays. Although both > install-info programs are in C now. This has helped in the development of multistrap, so this is welcome. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgp2VB9p3CHU5.pgp
Description: PGP signature