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
> describing.
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.
____
Reply to: