Re: Embedded Debian (was: compaq iPaq)

2000-08-18 Thread Chris Rutter
On Wed, 16 Aug 2000 14:14:24 Ben Armstrong wrote:

> For the most part, I think there is enough flexibility within Debian to
> pick and choose the smallest tools that will do the job from among the
> binary packages.  Where Debian currently falls short, we can create -tiny
> versions of packages as needed.  Most useful optimizations that can be
> done at compile time can also be used to create binary packages to save
> people the time and bother of compiling it themselves. 

Yes; I have an idea for a solution to the problem:

  * For each package, logically create another two packages (although there
could be many categories): `-small' and `-tiny'.

  * Write a script that will take a binary package and, based on guesses,
squeeze it down to size; e.g. squeezing binaries, removing documentation,
removing bash or Perl scripts (depending on whether the target supports
bash and perl), header files, etc.

  * Define a mechanism so that a binary package can contain a file in
`DEBIAN/', called (say) `squeeze-small' and `squeeze-tiny', overriding
the script's guesses, and specifying more exactly how to squeeze the
package to its corresponding smaller version.

  * Define a mechanism so that a source package can contain a file which
specifies a list of `small' options (e.g. portions of glibc to compile
in) which can be defined to create a squeezed package in one form.
(I think few packages would need these.)

  * Write a tool analagous to the task selector to build these `small'
packages and create filesystem images out of them.

  * Package up newlib and friends and make them provide libc6. :-)

c.




Re: Embedded Debian (was: compaq iPaq)

2000-08-19 Thread Chris Rutter
On Sat, 19 Aug 2000 09:22:12 Glenn McGrath wrote:

> hmm, im not sure its practical to create extra binary packages, wouldnt
> it be more effective to exclude files from regular packages as its
> installed.

I was suggesting that the script would create them on-the-fly -- they
wouldn't reside anywhere as such.
 
> It could use an external script like you mention in your second point.
> 
> You could have some sort of wrapper around dpkg to do it, would be
> easier than creating new tools, new packages.

That's the sort of thing I meant, yeah.  I suggested the existence of a
tool which would handle all this sort of thing to create a whole
filesystem, or individual small packages which could be transferred onto
an embedded system and `dpkg -i'ed.

c.