On Sat, Jun 18, 2005 at 11:35:21AM -0500, Ian Murdock wrote: > Please don't be dramatic. I'm not demanding anything. I'm expressing a > concern, and a legitimate one.
I'm not the only one who isn't convinced of the accuracy of the predictions which form the basis of your concerns. First, they're based on the RPM story, and there are many differences (technological, social and logical) which lead me to feel that it doesn't model Debian very well at all. We live in a different world, and we did even then. The fate of Debian does not rest on the possibility of creating one binary package which is compatible with every Debian derivative, (which is fortunate, considering that this has not been feasible for a very long time already) and Ubuntu doesn't change that. For open source software as a rule, the most important interface level is the source code. GNOME developers, for example, maintain a very successful collaboration, despite using a wide variety of quite incompatible development platforms. Linus Torvalds' stated position on interface compatibility in the kernel[0] is in the same vein: it's the kernel programming API which is important, not the binary module ABI. [0] http://kerneltrap.org/node/1758 Practically speaking, the differences in compatibility between Ubuntu and Debian is of as much concern as those between Debian stable and Debian unstable. New interfaces are added in unstable constantly, and software is adapted to use them. Binary packages from unstable are rarely installable on stable without upgrading other supporting packages. Third party packagers must choose whether to provide builds for stable (if the package builds), unstable or both. So far, this has not resulted in a problem for Debian. The cost of guaranteeing ABI compatibility is high, and the benefit to free software is marginal. It is a problem for proprietary software vendors to be concerned with, and we should leave it to them. We have more important work to do, and we're doing it in source code form. > I'm more worried about the future; and I still haven't seen anyone > address my initial question, which is why Ubuntu is tracking sid on core > things like libc in the first place. Michael K. Edwards provided you with one explanation in <[EMAIL PROTECTED]>, earlier in this thread, which is pretty close to the heart of the matter. It has to do with the fact that Ubuntu is on a radically different release schedule than Debian. These things are entering our development branch now because they're going to be shipping on CD-ROM in October. > The value you add is around the edges with stuff like X.org and GNOME > 2.10. I'd like to see you do that in a manner that promotes compatibility > with sarge, just as we're doing at Progeny as we move forward in these > same areas. But I certainly understand why you want to move forward in > these areas.. I do as well. > > The core is a completely different issue. Where at the core do you add > value? Ok, perhaps you can get a bug fix in here, better support for > an architecture here. But are those things worth breaking compatibility? Surely you can see that there is quite a lot more to what we do than GNOME and X.org, both technologically and organizationally, and our release process is part of it. It is common sense that new feature development should be based on a development branch, not the previous stable release. If Ubuntu had somehow been constructed atop Woody, rather than unstable, consider how much more difficult it would have been for Ubuntu patches to be used in unstable. This would have been like forward-porting patches from Linux 2.2 to Linux 2.6. > If your changes are important enough, they should be in Debian too. > If they aren't, they're not as important as compatibility. This seems to imply a belief that the binary compatibility differences which concern you are the result of Ubuntu-specific patches. This is not the case, and never has been. If instead you meant "changes" in a broader sense (such as earlier adoption of certain versions of software), see above regarding release cycles. > "Debian packages just work" has been a truism for *years*, and it's been > one of our key technical selling points. I don't want to see that fall by > the wayside. This thread is a perfect example of what will happen if we > don't worry about this stuff *now*. I've seen this movie before. "Debian packages just work, in the environment for which they were intended" would be a more accurate assessment. This has nothing to do with binary compatibility, and everything to do with rigorous packaging practices (which is the true basis for this selling point). It has never "just worked" to mix and match binary packages from different releases of Debian, or packages from different Debian derivatives. > If there's ever been or ever will be a perfect time for Debian and > Ubuntu to sync up, it's now. Sarge is out, and there is significant > momentum within the project behind the idea of fixing the release cycle > problem, so it seems likely that etch will be out in some predictable > and reasonable amount of time. Why not take advantage of that? Better > yet, why not help make it happen? Over the past weeks and months, during which time you've told the press that you think Ubuntu is bad for Debian, developers from both projects have been in the trenches exchanging code and coordinating plans between Ubuntu and Debian regarding GCC 4, glibc 2.3.5 and X.org (for example). Several components and transition plans which have been developed, tested and proven in Ubuntu are now in the process of being adopted in Debian unstable as well. > Why not, for example, work with Debian on putting together a plan for > migrating to GCC 4 rather than just plowing ahead on your own? Going it > alone is sure to cause compatibility problems that make the current ones > pale by comparison. I see that you've already been corrected by others on this point. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
