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.... > > > I understood your point, unfortunately it doesn't look like there's much > > > to do except giving up all the other benefits that I expect from this > > > way of handling dependencies on shared libs. > > > 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. 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. 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 ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
