[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [BusyBox] My brain hurts again.
From:       Rob Landley <rob () landley ! net>
Date:       2004-06-25 11:11:08
Message-ID: 200406250611.08613.rob () landley ! net
[Download RAW message or body]

Wow, if you "insert file" in kmail it inserts a null byte at the end that 
truncates your message.  So that's why it was asking about all characters 
fitting it the encoding.

That's annoying.

On Thursday 24 June 2004 18:13, Glenn McGrath wrote:
> The only difference between any of the archiving applets should be
> get_header_* and *_main, everything else should be common between
> archiving applets.
>
> get_header_* reads a file headers in the specific format and converts
> them to a commoon format to be used by the common code. (i also have a
> patch here somewhere to use struct stat as a sub-structure of
> file_headers_t, could be usefull to pass to stat directly)
>
> the *main function can handle parsing the intitial and trailing header,
> but its gets more complicated when there are multiple levels of archive
> handling.
>
> dpkg is an ar file with .tar.gz files inside, so being able to handle
> multiple levels was important to me (and still is if we are to keep
> dpkg-deb)

I had more to say last time, but basically "I don't use dpkg".

> About 6 months ago (before i got distracted with a job) i was working on
> a gpgv applet for busybox, i never put the crypto in it), the master
> plan was that it would be used to verify packaging metadata.
> I actually have that patch still, but its a bit crufty now,
> http://people.debian.org/~bug1/busybox/gpgv-4-WIP.diff.bz2

Dunno what gpgv is.

> gpgv has packets which can be base64 encoded and then gzip'ed, so again
> there gzip was used inside a different archiving format.
>
> I think the flexibility of being able to use gunzip internally, without
> necessarily havinga user visible gunzip applet is usefull.
>
> > If dpkg support's going to be removed anyway, presumably this stuff
> > could go back into tar.c, and then more or less removed if the "shell
> > out to a filter" code could be factored out to be shared by both
> > compress and decompress?
> >
> > (Are there any objections?)
>
> I dont object to moving get_header_tar_bz2 around, but i would like to
> be able to keep an internal gunzip. That is, be able to compile tar -z
> support and have gzip internally linked, rather than requiring a user
> visible gunzip.

Currently we fork and exec for archive creation, which is what it was doing 
for gzip already and I just extended it to bzip.

What we could do is some variant of "run_applet_by_name", that forks and runs 
gzip or bzip2 internally using the same basic logic we've got now, only it 
would only look for an external one if it couldn't find the built-in 
functionality.  (Thus it wouldn't get confused by a chroot environment as 
long as it was properly built in.)

How much would this bloat the resulting busybox vs the library wrapper 
approach?  It would basically mean you'd need the gzip_main and bzip_main 
functions, but it's a much more generic way of doing things.  (AND we need to 
get this to work in order to make the standalone shell work, although the 
real problem there is cleaning out the command shell to be reentrant in order 
to run shell scripts...)

> Glenn

Rob
-- 
www.linucon.org: Linux Expo and Science Fiction Convention
October 8-10, 2004 in Austin Texas.  (I'm the con chair.)

_______________________________________________
busybox mailing list
busybox@mail.busybox.net
http://codepoet.org/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]