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

Re: space considerations

Bastian Blank wrote:
> some time ago, joey hess calls libd-i bloated. a few time before i added
> many code to them which enlarges them by 13KiB uncompressed on powerpc.
> at the same time a added a multicall binary to di-utils which wraps a
> few of the functions for shell scripts. i also moved the shell and
> mapdevfs binary in. the resulting binary had a size of 11 or 12KiB (the
> glibc adds 8KiB overhead to each executable). joey hess removed that
> modifications and also he removed the explicitely requested exec(log)
> command. this removes 3KiB (uncompressed), readding execlog adds 5KiB of
> code.

mapdevfs has no business in the d-i base system (on a floppy), nor does
the special-purpose function it calls have any business in
libdebian-installer. I have already explained why.

I removed the "exec" program because it was badly named (with disastrous
consequences if a shell script did "exec foo" and it was not present),
undocumented, and did not work, as it was unfinished. Colin Watson has
since shown how to write it in a line of shell. Someone should put that
in di-utils (and find places that still pipe to logger and fix them) but
don't call the program "exec".

> some days after he ask why we use busybox-cvs. i don't respond further
> but this was mainly space considerations. we decided to use the included
> ash (now it is a dash) and later the modutils. this saves something
> between 50 and 60 KiB compressed on i386. (and there are some KiBs left,
> because we currently provide the iproute and old ifconfig/route
> interface)

These are of course good reasons to use busybox-cvs and I'm glad to be
aware of them now. I asked the question because I was not aware of the
history; you connected two unconnected threads.

> i have some modifications for libdi pending, it moves some unused
> functions to another lib and partialy provides weak dummy symbols (i
> hope they work as expected, the testing cycle is not yet written).

This is not the time to be making any modifications to libd-i in
unstable. I expect we will be getting a beta release out this week
(details coming soon). Do it in a branch, do not upload it to unstable.

I do not understand why we should need weak symbols in
libdebian-installer. That suggests they you are trying to provide some
form of backwards compatability, which is not necessary in d-i, and will
surely just bloat it further.

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: