This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] change GLIBC PPC64/ELF2 ABI default to 2.17


Roland McGrath <roland@hack.frob.com> writes:

> I'm less knowledgeable about the RPM/Fedora/RHEL packaging details than
> I used to be.  But I believe it's the case that rpmbuild examines the
> actual binaries to see what SONAME+version-set combinations they
> require, and makes those the dependencies of the binary package.
> Likewise, it examines DSO binaries to see what SONAME+version-set
> combinations are provided, and makes those abstract dependency tags
> (called "Provides"/"Requires" in rpmspeak) what the binary package
> containing a DSO lists.  Binary packages don't usually have explicit
> package dependencies on the binary packages that provide the shared
> libraries they use.  The SONAME+version-set dependency tags are
> satisfied by the matching tags on the library binary packages.  (My
> description is a bit overly cumbersome because I can't remember all the
> terminology that rpm uses for the dependency features.)

This is similar to the way that it works with dpkg, but with dpkg
(assuming one is using the new deb-symbols method; the older method
required the library package maintainer to change metadata when new
symbols was introduced and tended to generate tighter dependencies than
were required) the dependencies are determined by looking at what symbols
the executable needs, after the build, and consulting a file provided by
the library package that says what version of the library package first
provided that symbol.  This generates the least restrictive dependency
that can satisfy all of those symbols.

In this scheme, it's perfectly legal (if weird) to say that foo@2.19 first
appeared in 2.17, and this will result in the correct dependencies in the
binary package.

> This methodology exactly mirrors how the underlying dependencies between
> binaries work and are checked at runtime.  Thus the package system does
> not impose any artifical dependencies: if you build a package on a newer
> Fedora system but it does not use any symbol versions introduced
> recently, then you can install that package on an older Fedora system
> just fine.  That's entirely sensible, since it should run just fine
> there too.

Correct, that's the same in the dpkg scheme.

For more exhaustive detail, see:

http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-symbols

-- 
Russ Allbery (eagle@eyrie.org)              <http://www.eyrie.org/~eagle/>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]