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

Re: using perl in preinst script

On Tue, 28 Dec 2010 15:07:56 -0800
Russ Allbery <rra@debian.org> wrote:

> Carsten Hey <carsten@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

> > 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.


> 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

Attachment: pgpaRyGBYwFkI.pgp
Description: PGP signature

Reply to: