On Tue, 28 Dec 2010 15:07:56 -0800 Russ Allbery <r...@debian.org> wrote:
> Carsten Hey <cars...@debian.org> writes: > > > We are not that far away from being able to implement this plan. The principle reason to consider not having perl / perl-base installed as part of a minimal base system (note that I don't claim that this involves using what Debian deems Essential) is to achieve a flavour of Debian with installation sizes below 64Mb, preferably closer to 32Mb. Therefore, Emdebian did a lot of work in this area for Lenny and finally got a version out which we called Emdebian Crush. It was so much work that there will be no subsequent version until at least after Wheezy. It's not just the cross-building issues (which are significant and which are waiting for Multiarch), it's not just the avoidance of perl in the final system (which is - or was with Lenny - also non-trivial), it is the rest of the system. 0: Custom installation methods are needed, which make testing harder 1: Other packages have to be rebuilt with different configuration options to drop long dependency chains like ldap, again complicating debugging / testing. 2: coreutils is another favourite for replacement and even a maximally reconfigured busybox cannot do the full job - dozens of maintainer scripts and other utilities rely on options for common commands which just aren't supported by busybox. (Not counting the problems that the Debian d-i team prefer to use a version of busybox which is old compared to busybox upstream stable.) 3: As Russ points out, working out the actual dependencies of the revised packages is just hard. There are other distributions out there which can handle these problems using the upstream sources but what makes Debian appealing are the maintainer scripts, the coordination, the way things fit together and these benefits are easily lost when making fundamental changes like those needed for Emdebian Crush or a similar sized installation. Even doing all that and getting down to under 64Mb, the number of machines which need such a constraint is getting small - most of the ones that people think of actually have constraints closer to 16Mb or less. At that point, you have to look at uClibc, busybox, customised kernel, a shell, a bit of networking and, umm, that's about it. That isn't Debian any more. It's a truly vast amount of work and what we'd get isn't really what these devices actually need. I've been working around these problems for years now, it just isn't achievable without an insane amount of resources and Debian/Emdebian doesn't have even a fraction of what would be required. Pushing this further is, IMNSHO, a sad case of NotInventedHere syndrome. Just because Debian doesn't have a way of doing this does not mean we need to invent a way of doing it when others have already solved the problems in ways which aren't compatible with how Debian needs to operate. If you want Debian/Emdebian on your system, be prepared to use a "modern" amount of SSD storage (>= 128Mb) and get something you actually recognise as Debian. It'll make development easier because the debugger can work on the same symbols as on your main desktop workstation. > > After debootstraping the minbase variant of sid, installing file-rc > > and removing insserv, there is not much perl left in the newly > > created system. The remaining perl library packages could be > > removed after installing debconf-english. Far better to use Emdebian Grip which removes stuff from the existing packages without changing compatibility or functionality. It won't make the installation size minimally small but it'll still be 40% of the size of the equivalent Debian installation. Small enough for most cases. http://www.emdebian.org/grip/ > Removing Perl requirements from the base system is not the hard part > of removing something from essential. It's not the only hard part of making a minimal system either. > The work required to fix package dependencies for the removal of > perl-base from the essential set is extensive enough, not to mention > unlikely (at least IMO) to be something that enough Debian developers > are willing to work on, that I don't think it's worth taking extra > precautions just in the unlikely case that it would happen. Sadly that's all too true. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
pgpfbS7ub6gRY.pgp
Description: PGP signature
