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

Re: Creating a rootfs with grip packages



On Fri, 27 Mar 2009 22:13:39 +1100
Brendan Simon <Brendan@BrendanSimon.com> wrote:

> > So you just need a smaller rootfs - OK, I'll look at an option in
> > multistrap that omits the Required: packages and leaves it completely
> > down to the list of packages specified. However, you will need to be
> > careful with that selection and that rootfs will still need perl and
> > glibc etc. It is still Grip.
> 
> Crush could be good for me too, but since Crush only really supports arm 
> at the moment, and filesystem space is not an issue, then Grip is a 
> safer/better option as the packages are available for many architectures 
> in precompiled form, and should be well tested and widely used on other 
> systems and therefore should be more robust :)

True.

Crush is hard work all round. (Removing perl is hard work too.)
 
> Er, why does a rootfs for my target "need" perl ???

Simple - various parts of the core Debian packages are written in perl,
some core packages contain scripts written in perl and these scripts
are actually used during normal installation and/or boot. Finally some
maintainer scripts are written in perl.

I might be wrong, but I don't think a standard Debian box can boot
normally without /usr/bin/perl. You certainly have enormous problems
configuring, upgrading or maintaining a Debian system without perl. I'm
guessing but it's probably the same with Fedora and other distros of
equivalent functionality.

> Is it do with init scripts or something ???

Compare Crush and Grip - everything that Crush does not do that Grip
does do is likely to be down to a tool somewhere in the chain being
written in perl. adduser is one.

> I would have thought bash or sh is all that was "needed" ???

Try it. ;-)

Even dpkg ships a perl module - that's not in dpkg-dev, it is plain,
simple, dpkg.

debconf *IS* perl and although there is cdebconf, it isn't a drop-in
replacement yet. (Bug filed, #451130, but no reply after Nov 2007.)

The kernel package postinst, postrm and prerm maintainer scripts are
written in perl. The sudo maintainer script needs perl.

Even debootstrap uses perl in some situations. Yes, honestly - it needs
either a compiler (in our case, cross-compiler) or perl for some
operations, especially when using --foreign. (And yes, that is perl on
the target device.)

neil@dwarf:~$ grep perl /usr/sbin/debootstrap 
	error 1 NO_PKGDETAILS "No pkgdetails available; either install
	perl, or build pkgdetails.c from source"

neil@dwarf:~$ grep perl /usr/share/debootstrap/functions 
if [ -x /usr/bin/perl ]; then
	PKGDETAILS=pkgdetails_perl
		perl -le '
	pkgdetails_perl () {
			perl -e '
			perl -e '
#!/usr/bin/perl

Despite all that pain, some people still think it is a good idea to
make python as central as perl. &£*%$"! nightmare.

> So it sounds like emsandbox could do most of what I want, but 
> that multistrap would be the better option as it seems to be more 
> versatile and is being actively developed to do some of the things I'm 
> after.  Yes ???

emsandbox is actively developed too but it is easier to use multistrap
than to adapt to how emsandbox wants to work because it's too biased to
Crush. To be fair, crush was all we had when emsandbox was designed.

Multistrap is the best option for Grip. I need to do some work on the
Grip webpages though.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/

Attachment: pgprngOAwpNn4.pgp
Description: PGP signature


Reply to: