On Tue, Jan 09, 2018 at 11:13:11AM +0000, Hugh McMaster wrote: > When I last checked, 33 packages FTBFS with freetype-config removed [1]. > That said, removing freetype-config was -- and still is -- my preferred > option. See bug #870618 for the request.
I think I ran into ~6 of them (because freetype-config is broken for cross compilation while pkg-config isn't). I guess patching all of them is the route of least long-term effort. Breaking 33 packages now is not the end of the world. We broke way more with the libtool split. > As discussed in [1], the reverse build dependencies would need to be > patched to use pkg-config. I'm not sure how easy that will be or how > willing the package maintainers will be. Well, stuff will FTBFS. That's an rc-bug and will quickly be eligible for 0-day NMUs. I guess this is two days sitting down and NMUing packages. > Okay. When building for the host architecture, freetype-config's output is > the same, whether pkg-config is installed or not. You are confusing terms here: You are *always* building for the host architecture. What you do mean here is building for the native architecture. Or rather having build = host. > But there are difficulties using freetype-config for cross-compiling. If we > were to remove the pkg-config logic, we would be forced to rely on the > autoconf values, which requires the linker to select the correct libraries. I don't understand the downsides with this approach. > Alternatively, as you point out, we could make pkg-config the default by > adding pkg-config as a dependency of libfreetype6-dev. This still limits us > to building for the host architecture, however. No, it doesn't. I sent a patch for doing exactly that in #871470. > Is one option better than the other? If the goal is to remove > freetype-config in the (near) future, then pkg-config is IMHO a better > choice for this transition. Yes, the one that works. :) > Helmut (and Steve), what do you think? I question the utility of marking libfreetype6-dev Multi-Arch: same. So let me discuss that matter. Why would you want the -dev package M-A:same? The usual answer is to use it from multiple architectures simultaneously. How do you use it from two architectures? You have to cross compile for at least one. So the utility *is* cross compilation. If your patch necessary to make it M-A:same breaks cross compilation then failed on the whole. If instead the package is M-A:no and works for cross compilation, then you (partially) succeed. A *lot* of -dev packages are (implicitly) M-A:no and that's not a (big) problem. We should stop seeing the M-A marking as the holy grail and start seeing the use. => The obvious solution is to make it M-A:no as long as it contains freetype-config. After freetype-config is removed, you can mark it M-A:same. > For now, to better manage Helmut's problem of having both pkg-config and a > foreign arch variant of libfreetype6-dev installed (without a native variant), > I propose we check for the existence of freetype2.pc in freetype-config. > > + /usr/bin/pkg-config freetype2 >/dev/null 2>&1 > + if test $? -eq 0; then > + [follow pkg-config code path] > + else > + [follow autoconf code path] I still question the utility of having two implementations of freetype-config and choosing them based on the presence of pkg-config. There are basically two case: Either the autoconf variant works or it doesn't. If it does work, remove the pkg-config variant. If it doesn't, remove the autoconf variant and depend on pkg-config. Anything else is inviting for trouble later. > This check will fail in Helmut's use case, forcing the use of autoconf. > The change won't fix the cross-compiling problem, but it will stop > the console being spammed with pkg-config warnings. > > Helmut, is this acceptable? Not at all. Helmut
