To Require or not to Require?
Bryn M. Reeves
bmr at redhat.com
Fri Aug 12 16:25:17 UTC 2011
On 08/12/2011 04:40 PM, Matthew Garrett wrote:
> On Fri, Aug 12, 2011 at 08:27:13AM -0700, Toshio Kuratomi wrote:
>> Rightly or wrongly, upstream libfoo-1.0 has some additional utilities that
>> access the PrivateData. Because the utilities are built from the libfoo
>> source, they can include the fooprivate.h header file and do this. When
>> libfoo goes to 1.0.1, upstream changes the definition of PrivateData and
>> updates the utilities to work with the new datastructure. Since the public
>> ABI stayed the same, the SONAME doesn't change and external programs
>> compiled against libfoo-1.0 continue to work but the utilities built as
>> a subpackage would be broken without stricter versioning.
> Upstream can change the ABI as much as they want without bumping the
> SONAME providing that the old interfaces are also present. It's entirely
> possible to end up with a situation where external binaries built
> against 1.0.1 won't run on 1.0.0 - the problem isn't limited to
I think Toshio is talking about the case where the subpackage executables are
using things that are explicitly outside of any defined ABI (since they are
compiled from the same source tree and have access to non-public headers and
types defined within them). In his example PrivateData was never part of the
interface that external code using -devel sees.
Third party code built against -devel and depending only on the SONAME is fine
in this situation as it sticks to the published ABI. In-tree code that plays
with non-ABI symbols will break and so may need a stricter dep.
It's easy to argue that this is a misuse of the interface or that the interface
is inadequate/broken but I'm sure there are packages out there with this problem.
More information about the devel