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

On Mon, Mar 29, 2004 at 04:01:30PM -0500, Branden Robinson wrote:

On Sun, Mar 28, 2004 at 07:27:33PM +0200, Sven Luther wrote:

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.

Ignorance is not precedent.

When we learn that non-free stuff is in main, our Social Contract obliges us to act on it, not immediately grandfather what we have found into our definition of "Free Software".

Ok, no problem, we will fix it. I investigated more here, and we are speaking about 200 bytes of m68k assembly, mostly A-trap instruction to access the mac rom. Benh is going to reverse engineer them, and i will try to get the m68k-asm of binutils-multiarch to generate a similar (or probably identic) binary, which will then be appended to the boot sector documented here :

http://developer.apple.com/documentation/mac/Files/Files-101.html

BTW, what about the values included in said boot sector data structure ? Do i also need to have someone reverse engineer them, and do a cleanroom implementation, or is it ok to just plain copy them ? Mmm, i guess it is ok to copy them, or i guess many many other software will have to be thrown out of main and into non-free too.

Now, that this will hopefully be solved, with a great expense of energy that could have been more usefully invested in something else, the main problem still remain, the one almost nobody commented on.

What about the remaining miboot, and the other m68k bootloader like amiboot ? These are all free code (GPLed for the most part), but can't be built using free or linux tools. In the ami/apusboot case, you need a amiga based gcc toolchain and the ixemul library, which altough it could be ported, represent considerable effort i believe it is not worth it. For miboot, it is even worse, as there doesn't seem to be a free linux toolchain able to generate macos code :

08:32 < benh> svenl: there are no tools in linux that can generate macos code

So, what is the solution for this :

  1. the true right way : implement the needed toolchain and/or port the existing ones. This would once and for all free these boot loaders, but represent considerable amounts of work. I am NOT volunteering for this, but i suppose that patches or help about this is welcome.

  2. as joeyh suggested, have a debian-installer-contrib package in contrib which would provide those boot loaders, and/or the needed stuff to build the boot images in the miboot case. This would be a bit complicated, as it will split the build process in separate packages, and thus add the risk inherent to the added complexity. Also, this pose the problem of debian-cd, which is also i believe a main package, and which would then not be able to incorporate those contrib stuff easily.

  3. make an exception for bootloaders, and have debian-installer download those from contrib. This is the pragmatic way, and i doubt it would be a threat to our freedom, as the only stuff concerned are dying out arches anyway, were the amount of effort involved in doing the right fix doesn't bring enough benefit to counterbalance it.

I think maybe 2) would be the best solution, since anyway we are doing some magic to get contrib on those CDs, i am not at all familiar with the actual build system, so this would need feedback from them. Am Ccing debian-cd list also, i hope this is right for that kind of info. Anyway, the plan would be to :

  1. have debian-installer build the free stuff.

  2. have debian-installer-contrib, which depends on the result of debian-installer, complete it with the contrib stuff, namely miboot boot floppies, amiboot and apusboot installation stuff.

  3. have the generation of the debian cd get the free stuff from debian-installer's result, and take the contrib part out of debian-installer-contrib at the same time it is gettting the contrib archive and putting it on the CDs. It will need to put them on CD1 though, and not on a later one where the rest of contrib goes.

Does this seem like a reasonable plan ? Is there time and will to implement this before the sarge release, and ideally before beta4 or the finalization of the beta3 powerpc update ?

Friendly,

Sven Luther

Reply to: