Re: Versioned symbols for 3.0?

On 18/05/10 18:50, Patryk Zawadzki wrote:
> The most important to us as a distribution is being able to
> automatically maintain dependencies for libraries that add symbols
> without changing their soname. For example g_malloc_n was introduced
> in glib 2.24.
> We currently need to manually test each app linked to glib to find the
> minimal glib version needed because just depending on the soname is
> not enough. We could rely on application maintainers providin correct
> versions in the configure files but 1) that's not always the case and
> 2) glib's very own macros can introduce new dependencies at the
> compilation time (for example after we upgraded to glib 2.24
> g_malloc_n was introduced to a number of applications that compiled
> and worked with older glib releases).
> On the other hand we don't have to do this for glibc as rpm
> automatically extract interface versions and glibc automatically gets
> these provides:
> ...
> Now if a package uses a symbol from a versioned interface, rpm will
> automatically add "Requires:" without us having
> to search through the history of API changes. I imagine the same thing
> can be done (or already is done) for other packaging solutions (deb,
> autopackage, zeroinstall etc.).

In Debian we do this by having this information in a .symbols file in the
package. When another package that uses that library is built, dpkg checks what
symbols of that library it uses, and adds the dependency accordingly (e.g. if
the package uses g_foo from 2.14 and g_bar from 2.18, the application will
depend on glib >= 2.18).

The .symbols file look like this[1] and is 'manually'[2] updated.

Not saying that the proposed change is not useful though.


[2] Where manually means applying a diff generated by dpkg

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]