[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian concordance

On Thu, Jun 16, 2005 at 04:03:32PM -0700, Michael K. Edwards wrote:
> On 6/16/05, Ian Murdock <imurdock@gmail.com> wrote:
> > glibc. Shipping X.org and GNOME 2.10 adds value, since sarge doesn't
> > ship them. Shipping glibc 2.6.5 vs. glibc 2.6.2 just adds
> > incompatibilities.

> 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.  Jeff Bailey and Goto Masanori, and a couple of
> other glibc packagers, are probably the people who can make genuinely
> informed comments; but having watched the final stages of glibc
> convergence for both hoary and sarge, I can say that they are
> significantly different "under the hood" despite both being labeled
> 2.3.2.

> On the Ubuntu side, divergences from the last Debian glibc drop that
> was merged into hoary (2.3.2.ds1-20) include subtle but important
> fixes to NPTL/TLS (with particular implications for heavily
> multithreaded apps on Sun's JRE), a fix for a sigsetjmp() issue that
> hits gcc 4.0, substantial rework of UTF-8 locale handling and Tollef
> Fog Heen's multiarch support.  The first two of these appear to have
> been addressed similarly in Debian's 2.3.2.ds1-21,

So if they were merged, why is it relevant that they were merged from hoary
to sarge instead of the other way around?

> but there's also a change to sched_[gs]et_affinity that resulted in
> GLIBC_2.3.4 versioned symbols and thus bumped shlib_dep_ver up to
> 2.3.2.ds1-21.

Indeed; and the shlibs model of identifying dependencies unfortunately is
not very fine-grained, with the result that it's a lose-lose choice between
making people manually set shlibs when building on sarge if they want hoary
compatibility, or shipping glibc in sarge with an incorrectly relaxed shlibs
that could let you install packages on hoary that won't work there.

So, maybe it's time to revisit the weaknesses of the shlibs system,
particularly as they apply to glibc.  Scott James Remnant had done some
poking in this area about a year ago, which involved tracking when
individual symbols were added to a package -- apparently, many packages
would actually be happy with glibc 2.1 or so (at least on i386), but we have
no way to track this...

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: