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
> weekend.
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
installer).
-Erik
--
Erik B. Andersen email: andersee@debian.org
--This message was written using 73% post-consumer electrons--
Reply to: