On Tue, Oct 19, 2004 at 09:16:17AM -0700, John H. Robinson, IV wrote: > The only difference is in *performance*. If there are other differences, > then there is a bug in one of the two compilers. If you are equating > performance with functionality, then we are going to have a very hard > time communicating.
I guess so. I'd consider a security update that significantly reduced the performance of the package due to a different compiler being used to be a severe error. I suspect the stable RM would agree. You apparently don't care, but I suspect you're in a tiny minority (and for the sake of the quality of Debian stable releases, I hope so). > > Huh? You ignored what I said: you can't make a stable update using a > > different compiler, because it can introduce both performance and (more > > importantly) new bugs, which is completely unacceptable for a Debian > > stable security update. > > Actually, later in my previous message I accepted your agrument on > pragmatic grounds. It's one real-life example of why depending on non-free components to build Debian is unacceptable. That's why Debian exists: to build an entirely free system--not "entirely free, except you'll need these non- free tools to actually build it". > You are the one that brought up the bogus argument that if the icc > packaged one were introduced into main, that any end-user would have to > accept the icc license. No, I didn't. I said that you'd have to do that if you wanted to produce the package, which is entirely true; if you don't do so, you can only build with a different compiler, which gives you a different thing. > This is almost akin to saying that if a package were built on a vmware > virtual machine, the end-user would have to accept the vmware license, > or that the package would have to go into contrib. This, on the other hand, is entirely bogus. Building in a VM doesn't change the output; building with a different compiler certainly does. -- Glenn Maynard