On Thu, Feb 09, 2006 at 06:59:02PM +0800, James Henstridge wrote: > Steve Langasek wrote:
> >>If Xft is updated to a new version of either of those libraries such > >>that those types are defined differently (altered struct layout, > >>different type sizes, etc), then the app also needs to be updated to the > >>new version. > >Ok, here's the problem with this argument. > >Yes, if one of the freetype types that's used in Xft/Xft.h changes, that is > >an ABI change... *in libXft* -- that's why we care about it! Because it's > >an ABI change in libXft, the soname of *libXft* should change. With the > >change of libXft's soname, there's no reason an application that is a > >consumer of libXft, but *not* a consumer of freetype, should care about > >libfreetype *at all*.[1] > The simple matter of fact is that when you ask for the Xft API in your > app (#include <Xft/Xft.h>), you also get the freetype API at the same > time. While some apps don't use it, we can't say that apps don't use > those APIs in the general case. You're right, we can't. But as library authors/maintainers, we can say whether we intend to *support* such abuses of the API. You can get a valid prototype of fprintf() on Linux by doing #include <sql.h> (from UnixODBC) instead of #include <stdio.h>, too, and we don't know that there isn't anybody relying on that -- but if they do, and they complain about it breaking, they are cordially invited to blow it out their ass. ;) The current policy of pkg-config prevents library authors from making their own choices about whether to support such API abuses on the part of applications. I don't think pkg-config should be imposing policies which prevent library authors from deciding what uses of their headers they intend to support. The current behavior of pkg-config *ensures* that the API abuses you describe will work, because use of Requires means they'll get the ldflags as well as the cflags; that makes pkg-config as it stands pretty suboptimal for anyone who *doesn't* want to get supporting their lib dependencies as part of the public API. > >On the other hand, there are plenty of cases in which an ABI change in > >libfreetype will *not* cause an ABI change in libXft. Addition or removal > >of functions, addition of typedefs, or removal or changing of any typedefs > >not used in libXft's ABI are all changes that should require an soname > >change in libfreetype but not an soname change in libXft. The present ABI > >transition in libfreetype is such a case. But because these applications > >are being encouraged to link directly to libfreetype, *even though they > >don't use it*, they have to care about ABI changes that should not affect > >them. > They are using it in conjunction with the Xft API. There is no clear > separation between the Xft APIs that use it and those that don't. Of > course, an app that only depends on Xft indirectly and doesn't use Xft's > APIs doesn't need direct linkage to freetype. They are using data types defined by freetype in conjunction with the Xft API. If they're using function calls from freetype without including freetype headers, they didn't get that idea from Xft's documentation or by reading the Xft headers themselves. Xft's maintainers should not be constrained by a pkg-config design decision to support people who think #include <Xft/Xft.h> is an acceptable substitute for #include <freetype/freetype.h>. > >The net result is that pkg-config's handling of Requires/Requires.private is > >directly causing churn in response to ABI changes in any indirect library > >dependencies, where this should be completely unnecessary on GNU/Linux > >platforms. It increases the chances of segfaults or other failures from > >loading two different versions of a library into memory, and correspondingly > >increases the frequency with which binaries need to be rebuilt in response > >to ABI changes that don't actually concern them. And it does this entirely > >to support a use case which, as explained above, should not actually exist. > The "app links to multiple versions of library A" problem is quite easy > to diagnose, and also makes it clear that an app needs to be rebuilt if > the old library version is removed (i.e. the app doesn't start). The > "app depends on the structure layout of the old version of library A but > doesn't directly link to library A" is more difficult to catch. The app doesn't depend on the structure layout of the old version of library A. It depends on the structure layout of *library B*, which happens to have *inherited* that structure from the *headers* of library A. It's entirely feasible for a library to do this without actually using library A at runtime; so then you get library B not linking to library A at all, but because it uses pkg-config to resolve the header reference, app C *does* get linked against it for no reason... > It sounds like your argument is that "Xft shouldn't expose the freetype > API". Given that this isn't the case, the direct linkage makes sense. > The freetype change in this case might not break many Xft using apps, > but that won't necessarily be the case next time this type of situation > occurs. No, that's not my argument. It's *true* that libraries should generally strive not to expose the APIs of other libraries in their own; they also should use linker scripts to avoid exporting internal symbols, use versioned symbols to avoid problems with multiple versions of the library, forward-proof their APIs so structs can be extended without breaking the ABI, and carefully check their ABIs with every release to make sure they aren't silently incompatible. But I still live on Earth, where lots of libraries are sub-optimally maintained. :) My argument is, *given* that such suboptimal libraries exist, pkg-config should accomodate this reality instead of amplifying the problems. > >- If library A's soname is correctly changed in sync with library B's, > > linking application C to library B is redundant. > >- If library A's soname is not changed when library B's soname changes, > > pkg-config's behavior does not prevent applications from being broken by > > the ABI change in libA. At most, it makes it easier to detect such > > breakage due to double-linkage of libB. > I'd argue that this is a useful feature to have, rather than having apps > break with no indication of the cause. Possibly so. I don't believe it outweighs all the other considerations, such as the large number of cases in which applications wouldn't break *at all* except for pkg-config pulling in unnecessary libraries. It's also not as though such breakage isn't debuggable; you just generally have to use a debugger, instead of merely looking at the output of ldd... > >>>This is unfortunate, because there are a great many packages that are > >>>inheriting dependencies this way on libraries they don't use. While it is > >>>true that an ABI change in the dependent library will *sometimes* mean an > >>>ABI change in the depending library, this is not always the case. As a > >>>result, this behavior of pkg-config causes unnecessary churn for packages > >>>depending on libraries in this scenario. In the case of libxft2, that's > >>>over 400 packages in Debian that are potentially affected. > >>Sure, unnecessary churn is bad and should be avoided. But you do want > >>to make sure that the churn happens when required. > >Er, the whole reason I'm objecting to the current behavior is that it *is* > >unnecessary churn. If the libfreetype ABI change affected the ABI of > >libXft, there would be no sense in trying to avoid the double-linking, and I > >wouldn't be bothering! :) > I understand that ABI changes are painful, but this doesn't seem like > the right way to try and combat it. Other options include: > * don't break the ABI. > * don't expose unstable dependencies in your own API. > * increase soname version numbers in lockstep with dependencies. > These all require upstream cooperation though. Sure. That makes them substantially less scalable. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
