Re: Dependencies on shared libs, take 2
On Tue, Jun 05, 2007 at 08:56:40AM +0200, Raphael Hertzog wrote:
> On Mon, 04 Jun 2007, Steve Langasek wrote:
> > On Mon, Jun 04, 2007 at 10:29:07PM +0200, Josselin Mouette wrote:
> > > 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.
> Would you care to elaborate? (What would you recommend? How do you expect
> it to improve the situation with those maintainers?)
Maintaining library symbol files with a tool that updates the symbol lists
with behavior analogous to dh_makeshlibs -V would be a significant
improvement over either dh_makeshlibs -V (force a shlibs bump for every
rev), or dh_makeshlibs alone (get too weak shlibs for any API additions).
Throwing a sensible error at build-time if the soname has changed without a
package name change is also something that needs to be done, as well as
throwing an error at build-time if symbols listed in the symbols file have
gone missing; I don't see these features mentioned in your proposal, but I
think they're part and parcel of a good implementation of what you're
describing.
Cheers,
--
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: