From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 Date: Tue, 2 Nov 2010 18:29:05 +0200 From: Michael Shigorin To: ALT Devel discussion list Message-ID: <20101102162904.GQ21965@osdn.org.ua> Mail-Followup-To: ALT Devel discussion list References: <20101031104442.GA1844@ssh.git.altlinux.org> <20101031213742.GA30284@altlinux.org> <20101101093238.GA5630@altlinux.org> <1288605115.4672.0.camel@shrek.croc.ru> <20101102001441.GA3718@altlinux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101102001441.GA3718@altlinux.org> User-Agent: Mutt/1.4.2.1i Subject: Re: [devel] Q: pkg-config: Requires.private == Requires? X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 16:27:52 -0000 Archived-At: List-Archive: List-Post: 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: 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 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. nchauvet, thx, I'll forward nchauvet, btw it was further recommended for the packagers to contemplate options like replacing "Requires.private: libsepol" with "Libs.private: -lsepol" (for libselinux.pc) 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 hm 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 i haven't quite understood what their problem was in the first place well currently we have the choice of: 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 - autoignoring Requires.private (thus breaking static builds); - pulling in extra junk for non-static builds (which would be !junk for static ones); - doing the replacement on a per package basis 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 private =/= static library :-) pulling in possibly unnneeded stuff for builds doesn't seem all that terrible nchauvet, /me's not a toolchain expert by any means, rather trying to build up communication where it seems lacking gvy, you might fall into on my only contrib to the pkgconfig mailing list, then er? :) for a bit of context, ALT widely uses autogenerated package dependencies both build-time via stracing the build and then mapping fopens into package/soname buildrequires and runtime via builroot analysis there is also quite a notion that starting to pull in possibly unneeded stuff is a regression hah! the complaint we got was because we moved unneeded stuff out of Requires or rather, libraries that applications didn't need to directly link against it sounded like their pkg-config was broken and ignoring .private fields when it shouldn't have 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? https://bugs.freedesktop.org/show_bug.cgi?id=31267 but as was said there, this should be taken to the pkg-config mailing list, not on an xorg bug thx ah, so I was duplicating ldv@ himself (btw he's a gcc/glibc hacker iirc and not exactly prone to whining) 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 ------ Linux.Kiev http://www.linux.kiev.ua/