Re: Debian concordance
On 6/17/05, Ian Murdock <firstname.lastname@example.org> wrote:
> On 6/16/05, Michael K. Edwards <email@example.com> wrote:
> > Speaking as someone with no Ubuntu affiliation (and IANADD either), I
> > think that statement is based on a somewhat shallow analysis of how
> > glibc is handled. [...]
> I don't doubt there were changes, even some worthwhile changes,
> between the version of libc in sarge and the versions in
> hoary/breezy. My question is: Are the changes worth breaking
> compatibility? It's a cost/benefit thing. And if they're
> important enough, why aren't they going into Debian directly?
Well, if anyone broke compatibility in the sarge/hoary timeframe, it
wasn't Ubuntu. The sched_[gs]et_affinity change in sarge is the only
one that broke an ABI and bumped shlib_dep_ver. The Ubuntu folks
quite consciously refrained from rolling out 2.3. in hoary;
demanding that they merge 2.3.2.ds1-22 and nothing else into breezy,
and therefore further postpone upstream's improved ppc64 support and
compatibility with other toolchain updates, seems like a lot to ask.
> I understand why Ubuntu was moving ahead of Debian before, since
> Debian was so far behind. But now that sarge is out, don't
> you think it would be worthwhile to give Debian a chance to fix its
> release cycle problems and, better yet, to try to help fix them,
> rather than simply saying "Debian is too slow/unpredictable for us"?
I really don't think they're saying that. Goto-san and the rest of
the Debian glibc team are appropriately cautious about moving 2.3.5
from experimental to unstable at the same time that many other things
are in flux. But if Ubuntu is going to move the toolchain forward in
breezy at all, they just can't wait. If anything, this will help
smooth the transition in Debian and speed up the etch cycle
accordingly. There's no particular reason why etch can't ship in six
or nine months, with better application compatibility between etch and
breezy than there is now between sarge and hoary.
> Again, as I've said before, it's *sarge* the rest of the world thinks
> of as Debian, not sid. So, "we're getting out patches into
> sid" or "we're tracking sid" or whatever doesn't really help anything.
I basically agree with you there; what would help, in my view, is a
sort of Debian/Ubuntu mini-LSB, ideally with a "white box" testing
framework that helps validate that a .deb is installable and likely to
function properly on some combination of sarge, hoary, breezy, and
etch. If, that is, ISV support is of interest, and you don't want to
go the LCC "multi-distro golden binaries" route.