On Mon, Aug 14, 2006 at 05:39:54PM +0200, Roman Zippel wrote: > Hi, > > On Fri, 11 Aug 2006, Wouter Verhelst wrote: > > > > What problems would that be? Toolchain problems don't solve itself and > > > the build speed doesn't seem to the biggest problem. > > [...embedded...] > > > The problem is that these users are not really visible, could Debian/CF > > > meet the release requirements on its own? > > > I'd really prefer to keep this at least initially separate and worry > > > about > > > a possible merge later. > > > > You're not honestly suggesting that we try getting a separate port for > > Debian/CF, are you? > > Well, I wouldn't exclude that possibility completely. Being a secondary > port doesn't has to be necessarily something negative. The problem being > here that the status of a "secondary port" is undefined. > A secondary port could accommodates the needs of a smaller port without > overly affecting primary ports, e.g. security updates could be released as > soon as they are ready for the primary ports.
Security updates is the least of the problems. The security team has stated on multiple occasions that they do not care how many ports are available; provided the buildd machines work, it takes just as much time for them to support 1 architecture as it would to support 27. The main problem is the people who need to coordinate everything: release managers, debian-installer authors, ftpmasters (who maintain ftp-master.debian.org), etc. For them, especially the release managers, the burden of maintaining an extra architecture increases super-linearly. And then I'm even ignoring the porters themselves; we'd suddenly have to support two ports, rather than one. I can also tell you that it will not help to say "but it doesn't need to be a release architecture". First, there's only so much time I can put in. I don't think I have the time to support yet another port. I wouldn't mind dropping armeb and start maintaining buildd hosts for a hypothetical CF port, but there would be so much more to do; it wouldn't even remotely be enough. And I hardly find the time to help track down m68k-specific bugs, for a port which *isn't* even vapourware at this point; I don't think getting a pure-coldfire port to work without dropping support for the regular m68k port would be a task we could successfully accomplish. Second, since we've had to endure this for a year now for the m68k port, I can tell you that not being a release architecture makes the work for a porter a *lot* harder. Your port suddenly isn't considered anymore for testing transitions; this means that your "pre-release" version (testing) becomes a lot less usable, since architecture-specific release-critical bugs are ignored for your architecture. Additionally, not being a release architecture means that bugs get lower severities and, thus, sometimes lower priorities by maintainers. ColdFire in Debian is going to be part of Debian/m68k, a separate port done by someone else, or not supported by Debian at all. Finally, again, I have thus far no reason to suspect that the difference in performance is going to be very noticeable. The longer PLT section is unfortunate, but there is no reason why the coldfire PLT implementation could not be used for classic 68k, too. This will slow down things a bit, but I dare say not incredibly. Additionally, the reduction in performance will most likely be somewhat ameliorated by a processor-specific C library for which we fully intent to write support, too. > > Supporting a Debian port requires processing time, disk space, and > > bandwidth on ftp-master.debian.org. > > Are there some numbers about this? I'm not really part of the FTP team, so I can't speak out of authority here. However, last I heard, the numbers were something approximating this: * You need about 20-30G of disk space per architecture. This includes not just the active .deb packages, but also the ones for testing and (eventually) stable; additionally, files that are no longer in use from Packages files are kept for a few days (I don't recall what the reason was, but when I heard about that, it seemed a pretty good reason to me). The amount of disk space required obviously increases as time passes, and also variates depending on at what point in the release we are (whether or not oldstable is still supported; how long it's been since stable was released, (and thus how much difference there is between stable and unstable), etc.) * The daily mirror pulse takes somewhere between 200M and 2G each day; there is no reason to assume that another architecture would increase that number by anything else than 1/12th of this. As a side note, however, I can mention that m68k usually does not keep up on busy (2G) days. There's a graph somewhere on ftp-master.debian.org, linked to from http://buildd.debian.org/ * The daily cronjob takes hours, at least. I'm not sure about the exact numbers, but they can be impressive; I don't think half a day or more is unheard of. Adding an architecture only increases that number. Obviously these problems can be solved, usually just by replacing ftp-master.debian.org by beefier hardware. However, because these numbers are so high, it is preferred that we do not try to create another architecture if it isn't absolutely necessary to get this support to work. I'm quite sure that "There will be some slowdown" isn't going to be a good argument against the above. "There will be significant slowdown" might be, but based on what I've been doing so far, I don't think that is going to be the case. I understand why you don't want this; and frankly, I agree. But Debian is not Gentoo or NetBSD. For either of those, it's not very hard to support an extra architecture, so they might very well do it without thinking much about it. Hell, NetBSD used to have support for a piece of hardware of which only some 200 machines were ever made. Debian, however, cannot think the same way, since adding another architecture requires far more manpower and far more resources than is the case for Gentoo or NetBSD. Besides, I'd think it'd be cool if Gentoo were to have m68k support; it would be great for those people interested in it. And there, you could just say "CFLAGS=-m68040" and be done with it. Or so. > I looked a little through some of the large packages, a lot of them are > not even m68k specific, followed by a few dbg packages, which are likely > to completely unusable on m68k. The largest package I found with some > value is the gcc-snaphot package. That may all be true, but I prefer to leave the decision of whether or not something is actually useful to our users. In the case of the dbg packages, I will tell you that they are not, at all, unusable; on the contrary. These packages currently only contain the debugging information that gdb can use if it's not embedded in the binary itself; they allow us to inspect core dumps and the like without requiring separate binaries. > > * More importantly, currently half of our buildd park are macintoshes > > that will not work with 2.6 kernels. 2.2 and 2.4 are scheduled to be > > removed from unstable, a move which will likely occur this month, > > maybe even this week. It will not take very long before glibc will > > drop support for 2.2 and 2.4 kernels, mainly because the glibc > > maintainers were amongst those asking for this change. > > While we can theoretically keep running our macs on 2.2 kernels and > > have them build packages, they will fail an ever-increasing number of > > things, much like the xargs issue that we currently see on a fair > > number of builds on 2.2 kernels. If our macs cannot run 2.6, we will > > need to find replacement for these somehow. We do not have the surplus > > buildd power to just forget about the 2.2-running machines and > > continue with those machines that do run 2.6. > > glibc might force us soon to drop 2.2/2.4 support, Yeah, glibc is the main reason why 2.2 and 2.4 are being kicked out of unstable right now. > I don't think we're going to survive much longer without tls support. > I'm looking into adding the support for it, but as a consequence we > might have a complete ABI change ahead of us, which we could use to > make the m68k a little faster (e.g. register arguments, better > alignment) and not slower. Right. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
