In his blog post about the m68k port he’s writing about the port being dead, because there’s simply no security support for it.
I have to admit that he might be right about it.
Although the m68k port is doing fine with keeping up, there are so many problems, that I doubt that m68k will be allowed to get back. My current list, of why m68k might be dead is:
- There’s no security support for m68k
- m68k has no glibc support in current versions (pthread thingie or so)
- m68k is not in stable
- packages are getting bigger and bigger and slower and slower all over the place
- there is basically no interest in supporting m68k in the majority of DDs
- some more minor reasons
I expect some of the above points to be taken against any possible re-inclusion of m68k, such as no security support and being not in stable, which is some sort of paradox because, you’ll guess it, m68k is not release with Etch and thus is not in stable. I guess this is difficult to understand when you’re not a m68k user, but from my point of view, this is forseeable because of past discussion about the status of m68k.
There had been spent so much energy on getting rid off m68k with the Vancouver Massacre, that it’s unlikely that a similar amount of energy will be spent to get m68k back in, because there wasn’t much energy spent for the time after Etch release. Ok, there was the introduction of etch-m68k on the mirrors, but as Joey already stated, that’s only part of the game.
There was a clear view of how to get rid off of m68k, but no vision of how m68k can exist outside of Etch. Now, the m68k support is basically gone, it’s even more problematic to keep up with other ports that are still considered for testing. The whole release infrastructure is based on the migration from unstable to testing. If a port doesn’t exist in testing, because it wasn’t released with the last stable, then it’s hard to get released with the next version of stable.
So, yes, I believe as well that m68k is pretty dead when no miracle happens soon…