[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Future of m68k - Etch and beyond

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

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!

Attachment: signature.asc
Description: Digital signature

Reply to: