Re: Dependencies on shared libs, take 2
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....
> > > 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
Reply to: