Re: Debian-installer, older hardware, boot loaders, miboot & amiboot & .. (original) (raw)

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

Reply to: