[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: package requests for grip

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

For examples of current scripting, see balloonboard:


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

Attachment: pgpzH1virsjbO.pgp
Description: PGP signature

Reply to: