Debian concordance

[Matt Zimmerman]

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
<625a0e650506171420e0920a5 at mail.gmail.com>, 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