On Sat, Mar 01, 2008 at 11:50:08PM -0500, Michael Casadevall wrote: > Well, it's been discussed time and again. It's overdue; its time we > bootstrap the coldfire port. Roman convienced me in his email that having > coldfire as a seperate binary distrubution is without a shadow of a doubt > the only SANE way we can support both coldfire and classic m68k.
I disagree. I explained why in a reply to Roman's mail, but before it got sent out, my laptop's hard disk died on me. Perhaps I'll still be able to recover that, but I'm not sure. 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. To me, the latter is not acceptable, so that leaves us with the former. You did raise a point that arm was able to have two or three ports in the archive. This is not correct: the armel port is only accepted because it was made clear that the arm port will be dropped after lenny; and the armeb port, for which I've done some buildd work in the past, is now well and truly dead. A second example is the SH port: that got killed off because the SH porters found that the only way to proceed forward was to split the port into two (or four) different ports, and that was not accepted. > I'm willing to do the grunt work on bootstrapping the port. I figure I > should try and point out why not old a seperate port is a better way > to go, why it won't kill classic m68k. > > Reasons for having a seperate port: > * We can optimize to each specific architecture - Debian is not Gentoo. Optimization is cool if we can do it, but it should not be an argument for or against doing something. - AIUI, with a working TLS implementation it is possible to compile an optimized library, and store it under /lib/tls/<something> so that the dynamic linker will pick it up depending on the subarchitecture you're running on. This will not make the optimization problem go away, but will at least mitigate it. > * It can be done now; we don't need to keep monkeying around with > binutils. > * We don't need to worry about any weird errors come from the > binaries due to the different opcodes and such These two are correct. > Reasons why the seperate port won't kill us: > * Almost all work done on coldfire can easily be used on classic > m68k; including kernel TLS and glibc porting (assuming CS ever > comes through for us) > * By generating interest in the coldfire port, we can probably > find more people who can fix gcc bugs in not only > coldfire, but classic m68k (the backend code for GCC is pretty > similar; 90% of it is more or less shared, with a few minor > differences). These also hold for any hybrid port. > * Freescale probably going to point to the fact that Debian runs > on coldfire (they did give us evalution boards), and might end > up commiting things towards the project once it gets off the > ground. Correct, but only as far as ColdFire goes. If we have two separate ports, then the m68k port itself will not get that interest from Freescale or anyone else. 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. Now if everyone thinks this is the right thing to do, then I won't object. But I just don't think it /is/ the right thing to do. Something else: I contacted Andrew Pollock, who once offered to ask within Google whether Debian people could hold meetings there, and he replied, confirming that this is still possible. The only problem, of course, is going to be the timezone issue: it's going to be possible to get us inside a Google campus, and hooked up with eachother through teleconferencing equipment; it's not going to be so easy to do this at 3AM local time, however. The best I seem to be able to find is to have something start at 21:00 in Europe, which is 07:00 in Sydney and 15:00 in New York (the US time could of course differ depending on the exact campus used there). That requires staying up late in Europe and getting up early down under; but everything else is far worse. Thoughts are welcome. -- <Lo-lan-do> Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
