Re: the next step
On Sat Sep 30, 2000 at 12:51:22AM -0700, Joey Hess wrote:
> Erik Andersen wrote:
> > Where do we upload things to? Can we get an archive area? I've had busybox
> > .debs ready for months now...
> And I've had bug #66604 open for months too. I need to track down some
> of the ftp maintainers and get this set up. I'll try to do that this
k. I guess somebody just needs a kick.
> > I've got a tiny little wget in busybox now -- I'd be happy to make
> > any changes wanted to handle the "http retriever" task.
> Maybe we can use it as the actual engine of the retreiver. The
> retreivers though have to all use a standard interface, and I think it
> makes sense to make a special module for the glue code.
I see. So more then just a retriever, you want something like the current boot
floppies http-fetch -- complete with curses/slang status bar, and such. Got
it. I can do this. I think we want an engine that works, and a pluggable
front end gui, so for example, someone could later write a microwindows
installer. I will just the curses/slang front end, and the underlying engine.
> Does your wget support resumes? How about download progress reporting in
> an easily machine-parsable format?
rfc2616 doesn't mention resume -- I presume you mean HTTP 1.1 Range support.
Yup it supports that. If the user specifies "-c" to continue, or if the server
responds with a "206" Partial Content, it uses HTTP 1.1 Range support to grab
the rest of the file. The only thing it doesn't do is it does not at all
support "chunked" transfer-encoding, which technically violates rfc2616, 3.6.1
(though for my purposes it was just bloat -- reading slashdot was not the goal).
> > For that "base tarball
> > installer" task, any reason not to use busybox tar, or is there somehow
> > more to it?
> It's clearly going to use busybox tar. But rather as with the http
> retreiver, there will probably be a certian amount of glue code that is
> best broken out into a module. Especially if it has to deal with configuring
> something or other in the unpacked base tarball.
k. Same deal as the http retriever -- the gui. I can do this too I suppose.
I'm wondering though -- with the configuration stuff -- we can just rely
on debconf for this, right?
> > Do you know what tools we do and do not want included?
> Not yet. Exactly what we'll need will be one of the later things to be
> worked out in the second month, when we're integrating everything.
> It seems likely that we will want to be able to build subsets of busybox
> as seperate modules. For example, if we're going to use the busybox wget
> as the engine of the http retreiver, then it needs to be on the boot
> floppy(ies), and we can't afford to put most of the rest of busybox on
> there. But we'd probably like to have busybox tar and gzip and probably a
> lot of other stuff available later on in the install process, so the
> retreiver will likely download a more complete busybox module with more
> stuff in it and overwrite the first one with it.
> Is this going to work for you? I understand it might add a bit of pain
> to the debian busybox build process.
Not that big a deal really. I already compile busybox twice for the .deb.
Adding a few more recompiles wouldn't be a problem.
> Oh, I should mention, I'm figuring just the following stuff will be on
> the boot floppy:
> - kernel (with ramdisk driver, tcp/ip support and nothing much else built in)
> - init & glue code
> - udpkg
> - udebconf
> - main menu support
> - network drivers
> - network configurator
> - http retreiver
> - whatever busybox programs the above needs
> Everything else gets downloaded. Whether this will really fit on 1
> floppy is going to be interesting to find out..
It will fit. Oh, yes. It will. ;-)
I'm sure it can be done. Though we may need to switch to libc5 or uclibc or
something more exotic (like the thin syscall wrapper libc thing on the RedHat
Erik B. Andersen email: email@example.com
--This message was written using 73% post-consumer electrons--