Re: what is the whole purpose of kernel-image-di?
On Wed, Feb 07, 2001 at 02:12:43PM +1100, Glenn McGrath wrote:
> Ben Collins wrote:
> >
> > I'm sitting here looking at an obvious build failure for
> > kernel-image-di on the sparc buildd, and I'm wondering what the heck
> > this package is for anyway. I mean, is this thing supposed to be
> > portable? If it is, it sucks at doing so, and if it's not, then is it
> > the intention that non-i386 is left out of this loop?
> >
> > Are the debinst folks not even considering non-i386 ports during
> > this development process? Am I going to have to go through all of the
> > installer and hack it to bits to make it work on sparc, just as I had to
> > do with boot-floppies, or is debian-installer being developed so that
> > all I have to do is create a boot-block installer, and a set of
> > kernel-image*.udeb packages to get it working on sparc? I'm very
> > concerned that portability is becoming an afterthought.
> >
>
> Network install to a i386 was/is the initial focus of development, but
> the modular nature of d-i should make it easy(or easier) to overcome any
> difficulties with a specific architecture, or even a different type of
> kernel (native Hurd install).
I can understand it being the first milestone, but it seems to be the
only focus, and nothing is being considered as to how it affects other
ports.
> Probably a lot of people (me included) arent aware of the difficulties
> of specific architectures, can you go into a bit of detail about what
> kernel config doesnt work for sparc ?
For sparc, there has to be atleast two different boot kernels. One for
sun4cdm (32bit CPU), and one for sun4u (64bit CPU). SPARC also supports
native netbooting (via RARP/TFTP). My main concern is whether or not it
is being documented as to how other ports need to handle getting the
installer working for it. Is there a checklist of what a port needs in
order to have support in the installer, such as a minimum of required
packages (boot loader setup, kernel-images, etc.)?
Note, every arch is different, which was the main reason for so much
speciality and hacking in the boot-floppies. It's held together by
ducktape and string. Have the issues involved in the boot-floppies
struggle with multi-platform support been brought into consideration of
the debinst design?
> To answer your last question specifically, portability isnt an
> afterthought, its part of the design due to modularity.
Sorry, but modularity does not beget portability. This assumption will
end up biting us in the ass later, if it is the only premise for
"portability".
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: