Re: debootstrapping m68k-coldfire
I do realize I'm the new guy here, but I do have an outside perspective,
and I do hope I'm not getting out of line here.
On Wed, 5 Mar 2008, Finn Thain wrote:
On Tue, 4 Mar 2008, Wouter Verhelst wrote:
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.
To me, the latter is not acceptable, so that leaves us with the former.
The problem here is that they are considering m68k and coldfire to be the
same architecutre; sorta like i386, i486, and i586. The fact that
freescale/Motorola considers it a seperate architecture, and offers
migration tools (similar to i386 -> Ithiumiun, or the aborted i386 ->
alpha of old), is enough in my book to consider it a seperate
architecture; if it is unable able to run binaries straight from m68k with
no modification beyond the kernel or glibc library, that's enough to
consider it a seperate architecture.
I'm going to play devil's advocate here for a moment; from the release
manager perspective, does it pay to release two ports, one for (there
perspective) a dead architecture like m68k (popcon lists 10 users, and I
know three of them are my machines), and another for an embedded
architecture. As it stands, the RMs are hestinate to have an embedded
architecture released; the only reason armeb was blessed as an offical
port was because NSLU2 users using armeb enabled popcon which provided the
justifcation; the armeb port has appartantly bitten the dust since the
issues with the NSLU2 network card in little endian mode were resolved.
As a user of Debain on not only ARM, but on my MIPS router (with NFS), it
works beatifully on an embedded system as long as you have drivespace
(granted, APT can be slow at times, but its a one time operation, I'm not
going to be complaing much; truely embedded distros like OpenWRT use
ipkg for this reason).
To me, a hybrid is not acceptable and the old should indeed gracefully bow
out and make way for the new. But, without user demand for CF, it is all
moot.
The problem with generating this that 90% (I'd go even as far as 95%)
percent of coldfire boards in existance do not have the required MMU a
Debian port would require. Only a handful of coldfire v4s have the MMU
chip (I think the v5 does too, but I'm not sure offhand). At best, any
coldfire port we'd do requiring glibc and a full MMU Linux will only be
usable by a subset of users. I suggested we do a uclibc-coldfire port, but
I've been told there would be issues on the number of libraries we'd have
to compile and use.
For myself, I'd switch to gentoo which doesn't have the infrastructure
overhead, and keep the old alive that way. Has anyone considered
addressing debian's infrastructure requirements? Is it not in Debian's
interest to encourage more spin-off distros?
If we have two separate ports, then the m68k port itself will not get
that interest from Freescale or anyone else.
How do you support that assertion?
At least from my perspective, coldfire and m68k are seperate
architectures, but from a compiler perspective, they aren't; assembler
code for one will more or less work on the other with some exceptions. Any
work done towards coldfire will be usable with minor tweaking in a worse
case scenario on classic m68k.
My main reason for asking for the ColdFire boards was so that the m68k
port could be spared from eventual, but certain, death. By creating a
separate ColdFire port, this goal will not be achieved.
It seems to me that if a hybrid could save our port, so can aranym (at
least until demand for CF justifies the inevitable demise of debian's old
m68k port).
I suspose the question needs to be asked; what are people doing with their
old m68ks. Most people around here are using them for (obviously enough)
buildds to attack the unstable queue. I popped over to netbsd, which is
the only other operating system distro besides Debain and Gentoo to
support m68k. The mailing list is completely dead looking at the archive,
and the latest NetBSD releases do not offically support any m68k
architecture as far as I can tell.
If I had actual m68k hardware, they'd probably be used for something
similar to what my NSLU2 right is being used for; file, email (and in my
case, wanna-build) servers. The problem is, I really don't see anyone
using their hardware for these purposes.
As for saving the port; well, effectively at the moment, we're already
dead. No (offical) testing, and I really doubt we're going to see a
lenny-m68k branch on the mirrors. The question becomes is resurrecting a.
worth it (IMHO, yes, Debian shold support as many architectures as
possible), b. fessiable (we were catching up on the unstable queue
until my ISP died, so again, I'd say yes), c. allowed by the RM (eh,
I'll be honest, I'm not sure if they'd let us re-release; they already
appear to consider us dead).
Michael
-f
--
To UNSUBSCRIBE, email to debian-68k-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: