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

Planning for the future (was: debootstrapping m68k-coldfire)

Well, the question is if both coldfire and m68k could be both hosted as seperate ports remains to be seen. On one hand, we have ports like mips and mipsel which only differ in the endian ordering. On the other hand, Debian SuperH died because it would require four (?!) ports. I'm not an expert in these matters (the only port I have seriously been involved with before this is hurd-i386 ... yes, you can laugh now).

As for a mini-debian distro, we could create a Custom Debain Distribition for m68k and such. Still, if we can provide a full Debian archive in addition to a CDD, that would probably be ideal. Unfortantely, with four buildds down, we're not in a good situation at the moment. In addition, we're not going to be able to release with lenny (baring a small^W major miracle).

Until we're at a state we can offically release with Debian again,
we should probably create an unoffical m68k Debian distro unless we want to leave what few users we have left running etch-m68k (and considering that we're looking at lenny+1 to re-release, thats a time period of quite possibly years. I'm willing to host such a setup, and I got a friend I can get into mirroring it (and a few other people here might). We can leave our unstable here, but we should have stable releases (with updates) hosted somewhere for users in the intern until we can meet release criteria.

Here's what I purpose what we do (and if we can ever do the video conferencing, I'd love to talk about this face to face).

- Figure out what we want to include in an embedded Custom Debian
  Distribition. I can figure out quite a few things just sitting here
  writing this emails. We should also offer this CDD for i686, ARM,
  MIPS(el), and any other embedded architecture to generate interest.

- Bootstrap m68k-coldfire as a seperate port to interest coldfire
  developers. If it proves fessiable to merge the two ports into one
  binary port, we simply need to provide an upgrade path.

- If we ever get a CDD off the ground, look into offering uclibc as an
  alternative since most embedded chips do not have an MMU

- Determine if we're going to break for Debian for the time being and
  release as an unoffical distro for etch r4, lenny, and whatever else is
  needed until we can merge back in.

There are probably a few things I'm missing, but that's all my brain can muster at 7:22am.
 On Wed, 5 Mar 2008, Geert Uytterhoeven wrote:

Date: Wed, 5 Mar 2008 11:03:56 +0100 (CET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: debian-68k@lists.debian.org, Wouter Verhelst <wouter@debian.org>,
    Michael Casadevall <sonicmctails@gmail.com>
Subject: Re: debootstrapping m68k-coldfire

On Tue, 4 Mar 2008, Roman Zippel wrote:
On Tuesday 4. March 2008, Wouter Verhelst wrote:
Anyway, the problem isn't that bootstrapping coldfire is hard; I
can do
that myself if needs be, and we'd have a working port within a few
months[1]. The problem is that adding another port isn't going to be
accepted by FTP masters: I don't recall who exactly, but an FTP master
did tell me that a coldfire port in Debian would only be accepted
if it
was either part of the m68k port, or replaced it entirely.

IOW technical reasons have no value when politics are involved. :-(
If we force everything into a single port solely out of political reason, it
gets a whole lot less interesting...

Why would a new separate port not be accepted? Because of disk and
mirror space requirements, or because of the overhead of having an
additional port (both in contrast to the (limited) audience of m68k and

If disk space and mirror space are the problems, perhaps there should be
a `Debian light' with less packages? Several big and resource hungry
packages will never be used on m68k anyway (and perhaps not even on the
slightly faster Coldfire). I'm quite sure we could fit m68k and Coldfire
versions of `Debian light' in the mirror space of a full Debian port.

This could be useful for other ports as well, and lower the entry
requirements for new ports (cfr. the several recently added architectures
in the Linux kernel).

If all else fails, maybe we should start thinking about OpenWRT/m68k or
something like that...



Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Reply to: