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


Package systems are only part of the issue.  If someone gets a binary by
whatever means (for example, ISVs often just distribute tarballs rather
than using any distro package systems, problematic as that can sometimes
be), then in the normal cases you can't start the binary up and then have
it die later with a symbol resolution failure.  The symbol version
requirements in the executable make it die safely at startup, before you
might have expected the program to succeed at doing anything, rather than
at some hard-to-predict time during the run when no graceful recovery is
possible.

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 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.

I don't know why you'd do it any other way.  (Well, I can think of some
well-intentioned reasons as well as some entirely indefensible ones,
but I don't think there are any actual good reasons.)


Thanks,
Roland


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