On Tue, Jun 05, 2007 at 08:07:20AM +0200, Mike Hommey wrote: > On Mon, Jun 04, 2007 at 02:32:10PM -0700, Steve Langasek <[EMAIL PROTECTED]> > wrote: > > On Mon, Jun 04, 2007 at 10:29:07PM +0200, Josselin Mouette wrote: > > > Le lundi 04 juin 2007 à 21:29 +0200, Raphael Hertzog a écrit : > > > > > Again, this doesn't take into account existing symbols that change > > > > > their > > > > > ABI across versions. I won't insist too much, as I have already > > > > > explained at large how heavy a burden it puts on the maintainer's > > > > > shoulders.
> How ironic the proper solution to this would be to use C++ symbol > mangling.... Two types can be ABI-compatible in C (on some or all architectures), but have different representations in C++ symbol mangling. > > > I agree that the benefits are worth the deal, but we should make clear > > > that the price to pay for these benefits is a continuous effort from the > > > maintainer. Therefore it should not be used by maintainers not aware of > > > its subtleties. > > Considering the number of bugs I see because of maintainers who don't notice > > they need to change package names due to upstream soname changes, or who > > routinely fail to bump their shlibs when new symbols are added, I think > > there is definitely room here for a recommended solution for maintainers > > that aren't watching the subtleties, even without trying to bump > > dependencies based on API extensions. > I think only a very small subset of libraries actually will benefit > having a symbols file. Most libraries and programs will benefit from > their dependencies having one, though. Well, I think that's exactly the point of the exercise; the benefit is for the reverse-deps, not for the libs themselves. I don't know about you, but I generally don't work on libs for their own sake. :) > I'm not a big fan of the global approach, though it can help having > figures. I would rather see this as a tool to enhance shlibs for > carefully selected libraries. For instance, I would first target > libraries with the most reverse dependencies. Good candidates for early adoption would probably be libraries with: - active maintainers - stable sonames - frequent API extensions - many reverse-deps So obviously glibc is at the top of the list, but it's also trickiest due to per-arch symbol differences. :) > Finally, why not add the symbol informations to the shlibs file (that > can be done in a backwards compatible way) instead of creating yet > another control file ? I'd rather we didn't, even if it doesn't break anything it still abuses the shlibs file format as defined in policy. And what happens if you (improbably) have an overlap between a library name and a symbol name? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
