[devel] Q: pkg-config: Requires.private == Requires?

[Michael Shigorin]

On Tue, Nov 02, 2010 at 03:14:41AM +0300, Dmitry V. Levin wrote:
> К сожалению, из-за тупых fdoшников пострадают нормальные
> пакеты, которые используют Requires.private именно для
> зависимостей статической линковки.

Может, попытаться выпрямить fdo'шников?  Ну там, рулесы им
процитировать?  На #freedesktop сослались на pkg-config FAQ
и предложили для начала выяснить в pkg-config на l.fd.o:

<gvy> hi folks, does "broken Requires.private" bell any rings to
      anyone?  lots of fd.o software has broken pkgconfig files
      using that instead of Libs.private as our (ALT Linux)
      builsystem folks say
<nchauvet> gvy, Requires.private isn't a strict pkgconfig
	   equivalent of Libs.private IIRC, the thing is that
	   this option still might not be well documented still.
	   But for example Requires.private also affect CFLAGS of
	   shared libraries.
<gvy> nchauvet, thx, I'll forward
<gvy> nchauvet, btw it was further recommended for the packagers
      to contemplate options like replacing "Requires.private:
      libsepol" with "Libs.private: -lsepol" (for libselinux.pc)
<alanc> I know the alt Linux guys have been whining that the new
	Xorg releases follow the Requires.private recommendations
	from the pkg-config FAQ, because that's not the way they
	want to use them
<gvy> hm
<alanc> but I haven't seen them follow our suggestion to take it
	to the pkg-config mailing list so the maintainers like
	Mithrandir can respond
<jcristau> i haven't quite understood what their problem was in
           the first place
<gvy> well currently we have the choice of:
<alanc> changing Requires.private to Libs.private like that seems
	like going backwards though, since you lose the
	inheritance of the required -I & -L flags from the other
	.pc files
<gvy> - autoignoring Requires.private (thus breaking static builds);
<gvy> - pulling in extra junk for non-static builds (which would
        be !junk for static ones);
<gvy> - doing the replacement on a per package basis
<nchauvet> gvy, autoignoring requires.private also break shared
           build when private 'headers' are involved
* alanc is tempted to call "breaking static linking" a feature,
  but then I'm well past 1980 in my library linking usage
<nchauvet> private =/= static library
<gvy> :-)
<jcristau> pulling in possibly unnneeded stuff for builds doesn't
           seem all that terrible
<gvy> nchauvet, /me's not a toolchain expert by any means, rather
      trying to build up communication where it seems lacking
<nchauvet> gvy, you might fall into on my only contrib to the
           pkgconfig mailing list, then
<gvy> er? :)
<gvy> for a bit of context, ALT widely uses autogenerated package
      dependencies
<gvy> both build-time via stracing the build and then mapping
      fopens into package/soname buildrequires
<gvy> and runtime via builroot analysis
<gvy> there is also quite a notion that starting to pull in
      possibly unneeded stuff is a regression
<alanc> hah!   the complaint we got was because we moved unneeded
        stuff out of Requires
<alanc> or rather, libraries that applications didn't need to
        directly link against
<jcristau> it sounded like their pkg-config was broken and
           ignoring .private fields when it shouldn't have
<gvy> hm, could you please remember who (or where) was that so
      that I don't duplicate the effort (presumably poorly) and
      spend everyone's time?
<jcristau> https://bugs.freedesktop.org/show_bug.cgi?id=31267
<jcristau> but as was said there, this should be taken to the
           pkg-config mailing list, not on an xorg bug
<gvy> thx
<gvy> ah, so I was duplicating ldv@ himself (btw he's a gcc/glibc
      hacker iirc and not exactly prone to whining)
<gvy> thanks, guys

(и кстати, "с таким настроением ты слона не продашь" --
в смысле что все козлы и не понимают очевидных вещей)

> Мейнтейнерам придётся самим решать, что с этим делать.
> Простых варианта два:
> - выкинуть Requires.private, поскольку статическая линковка это экзотика;

Годится, если и так нет devel-static; вообще это менее экзотика,
чем кажется в аквариуме с сизифами.  Припомни, что каждый раз,
как порывались её закопать -- приходили грамотные люди вроде
morozov@ и терпеливо объясняли, почему это была плохая идея.

> - добавить мусор в сборочные зависимости, после чего этот мусор попадет в
>   зависимости собранных devel-пакетов.

BR?  Этот вариант зацепляет по большей части hasher'ы, так?

> Есть и более сложные варианты.  На примере того же
> libselinux.pc, можно заменить Requires.private: libsepol
> на Libs.private: -lsepol
> 
> Тогда и зависимостей лишних не будет, и статическая линковка не сломается.

PS: также стоило сослаться на соответствующий апстримный баг:
https://bugs.freedesktop.org/show_bug.cgi?id=31267

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/