Re: Dependencies on shared libs, take 2
* From: Steve Langasek
* Date: Tue, 5 Jun 2007 02:56:14 -0700
> On Tue, Jun 05, 2007 at 08:56:40AM +0200, Raphael Hertzog wrote:
>> On Mon, 04 Jun 2007, Steve Langasek wrote:
>> > 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
If one will take look in the message with subject "checklibs...", one will
see similar items in the wish list on top of the script. But i don't
know much (yet) about build infrastructure to store information
script already (and can easily) generate.
For colleagues with python implemented ELF parsing, i will suggest to
help either elfutils, or binutils with their TODO lists.