Re: Debian-installer, older hardware, boot loaders, miboot & amiboot & ..

[Sven Luther <sven.luther@wanadoo.fr>]

On Sun, Mar 28, 2004 at 11:55:03AM -0500, Joey Hess wrote:
> Jeremie Koenig wrote:
> > The plan was to request a sarge-ignore tag on the "d-i build-depends on
> > miboot, which is in contrib", and try to find a better solution for next
> > releases.
> 
> This is the first I've heard of this. Has the sarge-ignore status of the
> GFDL docs really created such a slippery slope? I doubt it.

Well, we had it in woody boot-floppies, it seems.

> Sven Luther wrote:
> > Well, the solution would be to force add the miboot stuff to the
> > debian-installer svn tree, and use it to build. This would make
> > debian-installer contrib/non-free though, which is why i asked for
> > debain-legal help.
> > 
> > Note that one solution for this would be to make an exception for such
> > bootloader stuff, and have them in the debian-installer SVN, in a
> > boot-loader directory or something, and use them directly. This will not
> > break autobuild, and everything would be fine, except when you upload
> > said stuff to main.
> 
> That would violate the TOS for alioth. Do not check non-free code into
> the d-i subversion repository.

Well, the main point is, can you really speak about code when you are
contemplating a 1k boot-sector, which is why i have CCed debian-legal,
but got no response yet.

Also, i wonder how free a free replacement could be, if in order to work
it would have to be exactly the same as the one in question here. Do we
really need to consider source code for this one ? And in this case,
what would the source code of a small binary sector look like ? 

I thought that copyright mat not apply to such cases, where there is
only one way of making this kind of stuff work, and where the bit
sequence is accordying short.

Again, i have no real idea if this applies here, which is why i asked
for advice on debian-legal, let's see what comes out of it.

Also, maybe we should remove d-i from main altogether, since it depends
on non-free code in the bios of your motherboard ? 

> You are free to set up your own fork of the debian-installer package,
> call it "debian-installer-non-free", and upload it to non-free or contrib,
> and arrange to build the non-free boot images from it. That would be one
> way.

Yeah, a loosy way though. Or do you think that we should have a
debian-installer-contrib for the other boot loader which can only be
built on the native OS of the hardware ? 

> Another way might be to use the debian-installer package to build images
> with a dummy, free boot loader (all zero's, say), and provide a
> third-party tool to make the resulting images really bootable, by
> applying the real boot loader to them. The resulting images would not be
> official d-i images, but I think it would be ok to include the
> non-bootable ones in the archive, with an appropriate bug filed on d-i
> about their non-bootable status.

Yeah, but where will we take the non-free boot-loader (and it is not
even a full boot loader, just a stage 1 boot sector, which calls a few
MacOS ROM calls to activate HFS+ and call the stage 2 boot loader, i
guess there is hardly 1000 different ways of doing this). Anyway, do we
ask the individual users to do this step, and from where will they take
this boot sector ? do we provide a script for doing this ? 

Friendly,

Sven Luther