On Mon, Feb 26, 2007 at 07:46:32PM +0100, Roman Zippel wrote: > On Mon, 26 Feb 2007, Wouter Verhelst wrote: > > If that turns out to be not feasible, we'll then have to decide where to > > go; the options as I see them at that point are these: > > * Go with an emulator on an amd64 machine, and hope other Debian > > Developers want to support an architecture which from their POV only > > exists in emulation, > > * Discontinue the port, > > * Go with ColdFire support only for Debian, and *perhaps* provide some > > Debian derivative somewhere that will support "classic" m68k > > processors. > > > > But that discussion will have to be based in data and with the option > > there for the taking. > > It all depends on the place a port like m68k still has within Debian - is > Debian willing to accommodate a port like m68k with its wellknown > limitations. This requires of course compromises on both sides, but > currently I don't see it. The current conditions (e.g. like required build > speed) simply don't work for m68k and are basically intended to push out > smaller and slower ports. > IMO this requires a discussion at large - is Debian a distribution only > for the latest and fastest hardware or is there room for broader support > and how could the latter look like. I believe that Debian is willing to accommodate smaller ports like m68k. I also think it is incumbent on us to lead that discussion. Before we can do that, though, we have need to decide what we want. From what I've seen, other ports would be willing to support us in carving up the build list. For instance, s390 has little use for a fancy X desktop, but they still have to build everything too. To me it seems clear that compiling all of kde and gnome to run on traditional m68k hardware is a waste of time and cycles. However, how do we carve up the dependency tree so that we can support what we want without killing ourselves? I think if we have a reasonable plan on how to do what we want, Debian would be willing to support it. Developing the plan is the hardest part. Maybe we just need a more modular Debian. I don't mean at the fine-grain package level, but rather higher-up. Maybe something such that the dependecies look like the task selector in d-i (X Desktop, File server)? Key packages might provide non-X or non-KDE versions to optionally break the dependency change. -- Stephen R. Marenka If life's not fun, you're not doing it right! <stephen@marenka.net>
Attachment:
signature.asc
Description: Digital signature