Re: Debian concordance
On 6/16/05, Steve Langasek <vorlon@debian.org> wrote:
> On Thu, Jun 16, 2005 at 04:03:32PM -0700, Michael K. Edwards wrote:
> > 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?
It's not particularly; they just happened to be things I was aware of
on the Ubuntu side, and in verifying the corresponding changes in -21
I was relieved to see that similar (not, I think, identical) patches
went into sarge. Looks like Ubuntu has since adopted Debian's fix for
at least the TLS fix (not sure about the others, they may already be
dealt with upstream in 2.3.[45]).
> > 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.
Right. As I said, it's not surprising, and not cause for criticism,
that there's a need for a specialized environment if you want to build
multi-distro binary packages. It's a bit like building LSB RPMs,
except it's less painful because of the shared heritage and the
reduced need to lag drastically when there are fewer distros involved.
> 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...
It would be pretty cool to actually extract the external symbols
referenced in a package's ELF objects and deduce the minimum "happy"
library versions accordingly. Alternately, one could construct a set
of chroots with various historical library mixes and grind through the
ELF objects with ldd. That's really more along the lines of automated
"white box" testing, and might fit better into the sort of grandiose
post-build QA-role-signature chain I've proposed a couple times than
it does in the build process per se.
This holds especially when it comes to ISV certifications, to the
extent that that's of interest to Debian and/or derivatives. (Oracle
on Ubuntu, anyone?) ISV build processes tend to be rather stinky, and
post-build touch-ups to metadata are more practical than retrofits to
the build. (There's likely to be an alien / java-package style stage
in the process anyway.)
Cheers,
- Michael
Reply to: