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

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

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