Re: Dependencies on shared libs, take 2
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 <vorlon@debian.org> 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.
vorlon@debian.org http://www.debian.org/
Reply to: