On Mon, 30 Mar 2009 11:14:06 +1100 Brendan Simon <Brendan@BrendanSimon.com> wrote: > There are quite a few packages that are installed which I don't think > are absolutely necessary for an embedded system (depends on purpose). > eg. apt, wget, whiptail, etc. Even Crush requires apt, wget and whiptail. (whiptail and newt are required by debconf or cdebconf.) You appear to be expecting Grip to be able to give you what you seem unwilling/unable to wait to get from Crush. That will not work (and trying to support it will just delay Crush). > It seems libc6 depends on gcc-4.3-base which depends on grip-config > which depends on: > - apt, dhcp3-client, module-init-tools, wget, hostname, ifupdown, > mawk, net-tools, nano, ntpdate, passwd, udev, whiptail. The grip-config dependencies were carefully prepared to get from a standard debootstrap to a bootable system. Some can bear tweaking but those are really small packages anyway. I doubt that (apart from apt), you have more than 1-2Mb in total there. > I would argue that most/all of these are not necessary for an embedded > system. I disagree - they are not that large, not compared to perl which cannot be removed from Grip. Most cannot be replaced without fundamentally changing the core system by the use of busybox et al. > It may be for an emdebian system, where the target system is a > small Debian system (including apt update/upgrade capabilities), but > some embedded systems don't have that requirement. Those need to use (and therefore wait for) Crush where busybox can provide adduser functionality and replace coreutils (which is the real bloat, not the packages you've listed above). There again, the biggest bloat in Crush and Grip is glibc and the zoneinfo support. If someone actually spent some time on that, we could really move things forward. If the solution could be applicable within Debian, then Grip would also benefit. You're looking in the wrong places and blaming the wrong packages for the size of the Grip multistrap. > So if multistrap can be configured to only install the specified > packages, with or without dependencies, then that would be good. It will be possible to remove a few but not many. The majority of the packages are Priority: required and things break horribly when 'Required' is incompletely installed. It's one of the things that makes Crush hard work. multistrap cannot be configured to install any package without the necessary dependencies - that is the point of multistrap, that apt takes care of the dependencies, all of them must be met. If you need to change dependencies, then only Crush can help you. If 'change' includes the unwise notion of ignoring broken dependencies or forcing packages to install without their dependencies (which amounts to the same thing) then Debian or Emdebian cannot help you at all. > The other thing is to remove the packages as dependencies, either > removing grip-config as a dependency and/or the packages that are > dependencies of grip-config. No dependencies can be altered in Grip, only in Crush. grip-config can be modified because it's our own, but certain core functionality needs to be available on all Emdebian Grip installs and the gain would be small. Grip cannot function without grip-config - it simply won't install. Some of those reasons are bugs in Debian that are being fixed. > > 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 don't think multistrap uses the maintainer scripts, so we don't need > perl for that purpose, right ??? WRONG. multistrap prepares the maintainer scripts and makes them available to the final install process where they *MUST* be run after unpacking the root filesystem. Skipping the execution of the maintainer scripts in the unpacking of the .debs is not the full answer - the system is very, very broken at that point. Various packages will simply not function only after being unpacked - the maintainer scripts must be run and before first boot. Grip isn't aimed at the kinds of devices you are describing, Grip is for "a smaller binary-compatible Debian" - that is smaller than standard Debian but not ultimately small. Just because Crush is so hard, don't think that making Grip the same size as Crush is going to even be possible. Any Grip install will always be much larger than the "equivalent" Crush install - at the smallest end of the spectrum, the difference will be double, treble or more. Currently, Grip is 300% larger than Crush at the smallest end of the scale and getting any smaller means removing coreutils, glibc and perl - not tinkering around with wget or whiptail. > > 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. > > If not using apt, dpkg, etc on embedded system, then "configuring, > upgrading, or maintaining" is not required, and not perl. Sorry, that won't work. Configuring packages via maintainer scripts is not optional. It is simply not possible to merely unpack .debs as if they are .tar.gz and expect the system to work. Configuration needs to be done. Crush does it with ./emsecondstage (which calls dpkg --configure -a), Grip needs just dpkg --configure -a. For a start, there is no reliable way to set the root password of a foreign chroot - it has to be done after unpacking onto the real system (and before the first boot or you won't be able to login at all). There are also various issues around ldconfig (which is why there are so many /var/lib/dpkg/info/lib*.postinst files). > I would prefer to configure during the build/generation of the rootfs. Debian just doesn't work like that. Even Crush requires that the maintainer scripts are run on the target machine and uses patches to remove the perl from scripts that it doesn't need. Yet, by doing that, all sorts of new bugs arise. > >> 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 don't think I need adduser either. /etc/passwd (and friends) can be > specified or generated during the build. You're thinking of Crush - you cannot change dependencies in Grip so you must have adduser and you must have perl. Packages in Grip are not patched. > I'm not anti-perl, but would like to remove it if it's not really > required :) I can see advantages to having it for many purposes, but > not having the option to omit it would be good too. That "option" is only possible in Crush and causes a lot of bugs, pain and general breakage. > The other thing is to be able to store/cache the Grip packages > somewhere, so that they do not need to be downloaded every time I > execute multistrap (with --tidy-up option). apt does that for you. What is downloaded each time is the package lists. Once packages exist in the rootfs, apt will take those out of the list to download. In 1.9.0 there is also the option to extend --tidy-up to put the downloaded .debs into a different directory where they can be packaged as a source distribution. When checking whether to download a package, apt itself checks the dpkg data before checking for something in /var/cache/apt/archives - it is not necessary to retain the cache directly. > My "hope" is to be able to get a minimal system running with Grip. > eg. Kernel, C library, shell?, startup program (eg. init=). That isn't Grip, that's Crush. Grip has a minimum size more or less dictated by Debian Policy - there may be a few Mb to shave off the current size but not tens of megabytes. The minimal Grip system will still require glibc, coreutils, perl, dpkg, debconf, module-init-tools, grip-config, tzdata, adduser, base-files, base-passwd, dash, login, initscripts, pam, makedev, mount, sysvinit, udev and whiptail - plus a few more I might have missed - then the kernel and modules. (Grip will continue to use bash as well whilst that remains Priority: required in Debian.) > From there, the builder could extend to include sysvinit, adduser, apt, > ..., as required for their purposes. The idea of multistrap is to extend upwards, not downwards, in size by allowing complete systems to be prepared - from adding python (openmoko) to adding Xorg and XFCE etc. > Maybe there needs to be Grip themes or variants ??? > eg. Grip-Standard, Grip-Minimal ??? Dependencies in Grip cannot be modified - it is not possible in the Grip mechanism, it's the reason that Grip works at all. As for variants, multistrap provides constant variation *above* the minimal size but there is a floor and that floor includes perl. Unless Debian changes Policy on perl, Grip is going to absolutely require perl and there is no way of removing it. Only Crush has any chance of removing perl. Same goes for glic, coreutils and tzdata. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpRXb143ZVRm.pgp
Description: PGP signature