On Thu, 03 Sep 2009 21:32:45 +0200 "W. Martin Borgert" <debacle@debian.org> wrote: > Gertjan, this is exactly why we use Emdebian Grip in my company. > It actually *is* standard Debian, just smaller. Currently we use > Emdebian Grip *plus* a dumb scripts that remove more stuff, but > I hope, that this script will shrink with the Emdebian progress. Please share the details of what such a script removes as extra - there may well be ways of supporting such removals. (This goes for anyone else using custom modification scripts. Let's get such things out in the open.) There are three ways of adding such support: 1. Make it a default for Grip by adding this support as a part of the "usegrip" DEB_BUILD_OPTION. This would also make it easily available in Crush. This is the easiest for people to use but the option must be useful to the majority of users (as it requires making a second repository to be able to unset it). 2. Make it an option that emgrip understands but which specific vendors would enable - this means that vendor carrying their own package repository, possibly only a partial one. 3. Build the support into multistrap as an option - useful if the support involves a one-off process rather than ongoing changes to packages. For examples of current scripting, see balloonboard: http://balloonboard.org/cgi-bin/viewcvs.cgi/balloon/trunk/rootfs/emdebian/rootfs-config?revision=652&view=markup Things like vendor-standard files for /etc/ could be a useful enhancement to multistrap. It just needs a standard location, specified in the multistrap config file. If this would be useful, it could be added to the next version of multistrap. These may turn out to be simply too diverse to gain any real consensus on what it useful to most people but we won't know if all our scripts are hidden. I'm sure most people end up adding scripting to set device nodes and hostname and a few others - wouldn't hurt to make that something that multistrap can do via the config file, although which device nodes and how might mean that it's easier to do separately - discuss. :-) If there is "intelligence" needed, maybe a udeb could be created to do the calculations as part of the installer or a deb via the maintainer scripts. (grip-config is an obvious target for such support but it would need to be useful to the majority of cases.) > > With respect to updating packages, this is unlikely to be a > > problem on real commercial devices - I can't see releasing a device > > to a customer that has the ability to apt-get > > Same for my project. We use Emdebian to build the RFS and to have > a nice development platform (incl. apt-get), but we will probably > remove apt-get etc. from the final product. If customers ask for > it, we still can provide them with a developers RFS. Interesting option. Removing packages is always more of a challenge when you have i386 building armel etc. as you can't do a "normal" dpkg -P or apt-get --purge remove ; apt-get --purge autoremove. Having an alternative multistrap config that never installs apt could be useful - file a wishlist bug if that applies to you, it would limit the scope for orphaned packages. I think multistrap should aim to install less packages than the current base, the problem has always been that once you delve into those areas, you have to specify individual package names which means that your config quickly gets out of date as package names get updated in Debian. There is no Essential in Grip, you can easily need to specify library packages and those get out of sync very quickly. Ideas to the mailing list, proposals and patches via bug reports please. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpeV3C6DsyWP.pgp
Description: PGP signature