On Mon, Jul 29, 2002 at 04:48:30AM +0200, Tollef Fog Heen wrote:
> Anthony Towns has written some things [...]
More of a segue than a reply, but hey. Kibozing on irc shows up some
remarks like:
<Mithrandir> aj wants to be able to autobuild on other arches, so we'll
be able to build ppc images on i386. you think that's doable?
<joeyh> I don't see why that should be a requirement
<Mithrandir> to not require synching 20 arches or so. (11 in woody + hurd +
maybe some bsd stuff + maybe new arches?)
<joeyh> it's probably possible; nothing much is run when udebs extract.
It might be possible to get lib reduction to work
<joeyh> but it seems like a lot of extra work
<asuffield> Mithrandir: you'd need a cross-build of every boot loader widget
<asuffield:> that's a huge number of possible cross targets
<joeyh> asuffield: already have that mostly for debian-cd
<Mithrandir> asuffield: that's what I think might kill us, yes. I have _no_
idea how hard that is.
To be accurate, I don't care if you can autobuild on other architectures,
what I consider important is for one or fewer people (ie, whoever made the
last d-i changes, whoever's building CDs or just some automatic system) to
be able to get d-i up to date every where.
I think the most sensible way of doing this is to work out some way of
letting you construct the boot images on alternate architectures. Having
an additional, parallel series of autobuilders is likely to not
work incredibly well: some of them will become unmaintained as RL
intereferes, others will go down or break just when you need them, and
some architectures won't bother setting them up at all until we're just
about ready to release. Or that's what I'd suspect anyway based on my
experiences with the real autobuilders and b-f's in general. I could
be wrong.
The other aspect to this is that if we can make a technical solution,
then we don't have to worry about it again: CVS servers don't get bored
and shut themselves down, and anyone at all can easily get d-i images
built for every architecture, even if they're a third party hacker
somewhere who's never been seen on -boot. That's a win.
There's nothing _fundamentally_ undoable here, either. There are three
areas to worry about:
* getting the directory structure setup -- unpacking the udebs is
easy. running postinsts isn't as easy, but seems like it should
be easily avoidable: anything particularly necessary can be
scripted separately.
* getting the image created. This is pretty easy: it either requires
a loopback fs to be mounted and such, which can be done anywhere
except on the buildds; or it requires one of the magic tools that
let you create the image in place
* making the image bootable. This is trickier. One possibility is
porting milo, yaboot, silo, palo, etc to i386, and requiring
d-i images to be built either natively or on an i386. There
are probably others.
<mihtjel> yeah, I read it, and I understand it - although you seem to be
a bit more confident in d-i than aj was ;)
<Mithrandir> mihtjel: I've seen d-i. I've hacked d-i. I don't think aj has
either.
<Mithrandir> (and, yes, I probably seem arrogant, but that is because I know
what's possible to do. or something. :)
<mihtjel> well, if you're sure it's going to be used, there's nothing wrong
in saying that it is going to be used ;)
<Mithrandir> it's d-i and/or pgi. I can always back down on that one.
FWIW, I've poked at cdebconf and anna in the past, and I wrote
debootstrap, so I'm not completely naif. My only real concerns about d-i
are related to its debconf usage: that it still doesn't have a cfdisk
equivalent says bad things about that, IMO. But I'm biassed against
debconf, and rewriting all the UI stuff into debconf isn't remotely hard
enough to be a showstopper.
I think it'd be a huge win to have dbootstrap and/or pgi UIs available
concurrently with d-i (stick in a CD, choose a kernel, choose a UI...).
It'd let us do cool things like have an "Eye Candy" installer with
XP-like graphics, that we can target at kindergarten kids and distro
reviewers without having to worry about whether it'll work on m68k, eg.
I dunno if any of the "yay b-f's!" people are convinced enough to try
porting the core of it to udeb format.
In any event, it's a win to have each of the "features" of the
installer be separate: debootstrap, hardware detection, base-configu,
the distribution mechanism (udebs), the UI. That way if any of them turn
out to be fundamentally stupid ideas, we can drop it without having to
start completely from scratch.
Am I convincing anyone by talking about this, or am I going to have to
prove all this is possible with code?
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``If you don't do it now, you'll be one year older when you do.''
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
